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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
