[llvm-branch-commits] Thread Safety Analysis: Add guarded_by_any and pt_guarded_by_any (PR #185173)

[Marco Elver via llvm-branch-commits]

melver wrote:

> Looking at this together with #185172, I wonder why we're not directly applying these semantics to the existing attribute instead of adding a new one. I think your argument in the commit message makes completely sense: if all capabilities are required for exclusive access, then only one of them should be sufficient for shared access.

Some notes before I make the change:

I thought of retrofitting `guarded_by` with this new semantics initially - only reason I didn't immediately do it, is because it seems a little unintuitive to the casual user, who might believe it's the same as stacking the attributes multiple times (as the other attributes' behaviour). The new name `guarded_by_any` makes it clear there's something special going on.

I'd be happy to make the existing `guarded_by` behave in this new way, as that seems slightly cleaner to me. Only downsides are that it (1) might catch some users off guard and (2) we can't use the `__has_attribute` to check if the new behaviour is available (need to compare compiler version).

> If you don't think that's a good idea, we should probably dig out the logical expressions that @AaronBallman once worked on. But my intuition is that this is too general, and the semantics that you're implementing here are all that is needed.

Probably overkill and adds more complexity we need to maintain. The semantics proposed are well understood and relatively commonly found in the wild - yes, likely all we need.

Let me know which you prefer in the end.

https://github.com/llvm/llvm-project/pull/185173