[clang] [Clang][C++23] Implement P1774R8: Portable assumptions (PR #81014)

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> > I suppose the only question now is whether [[clang::assume]] should be treated like [[assume]] if it’s not applied to a function declaration?
> 
> THAT is an interesting question that @AaronBallman might have some comments on...
> 
> Effectively, we have TWO 'assume' attributes-
> 1- An openmp FunctionDecl attribute that takes a string 
> 2- The standard 'statement' attribute that takes an expression.
> 
> So the question is, how do we differentiate between the two? We have a few options: 
> 1- spelling: `[[clang::assume]]`/`__attribute__((assume))` currently work for the 'string' version, so make ONLY `[[assume]]` the C++ one. 
> 2- Argument: The OMP one takes a string argument, we take an expression. Bifurcate based on that? 
> 3- Appertainment: OMP is a function decl, standard is a statement.
> 
> Of the three, I lean towards 3 actually, I think that is perhaps the BEST idea, and is perhaps supported by our existing infrastructure already (if you have Attr.td set its targets right?). I'd like to see what Aaron has to say, but I THINK that is my preference baring any concerns.

For (1), I think we would run into portability issues with `__attribute__((assume))` because of GCC: https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#index-assume-statement-attribute. We could alter this somewhat and make `[[assume]]` and `__attribute__((assume))` the same, and `[[clang::assume]]` can be the oddity. We'd probably need a deprecation period to avoid breaking users though.

I think (2) is workable so long as we're not going to support constexpr evaluation of the argument for the OpenMP assumption attribute. e.g., that means we can never support:
```
constexpr const char *get_omp_assumption(SomeEnum E);

__attribute__((assume(get_omp_assumption(OMP::DoTheFancyThing)))) ...
```
because that is an expression rather than a string literal. I don't imagine WG21 would change assumption attributes to accept a single argument (esp of string type), so this option doesn't worry me too much about future-proofing.

I think (3) is also workable but perhaps slightly more risky because I can imagine WG21 changing the attribute to apply to declarations, though I think that's still a somewhat remote possibility. But if we went with (3) and WG21 did allow the attribute on function declarations, we'd be in a pretty tight spot. We could perhaps then fall back to (2) to work around it.

Would it perhaps be worth considering a variation of (1) where we:
* Add `[[clang::openmp_assume]]` and `__attribute__((openmp_assume))` as new attributes to do OpenMP assumptions,
* At the same time, deprecate use of `[[clang::assume]]` and `__attribute__((assume))` for a period of time with a fix-it suggesting the new attributes,
* Support only `[[assume]]` for C++ assumptions until that deprecation period has ended (perhaps not introduce it until that deprecation period ends, maybe??),
* Repurpose `[[clang::assume]]` and `__attribute__((assume))` to mean C++ assumptions, but give a really good diagnostic w/fix-it if we see a single string literal argument to suggest using `openmp_assume` instead.

This gets us to an end state where there's far less long-term confusion about OpenMP and C++ assumptions because they'll be totally divorced from one another in terms of the spelling?

If that's a bad idea, then my preference is to go with (3) followed by (2) followed by the originally suggested (1).

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