[clang] [libclc] [llvm] [openmp] [Clang] `__attribute__((assume))` refactor (PR #84934)

[Aaron Ballman via cfe-commits]

https://github.com/AaronBallman commented:

Thank you for working on this, it's definitely a complicated situation!

> However, libclc appears to be using __attribute__((assume)) internally, specifically, in one header that defines a macro that is then used throughout the codebase. I’m not familiar with libclc or OpenCL, so I’ve added omp_assume as an alternative spelling for the OpenMP attribute and replaced the attribute in the header in question with __attribute__((__omp_assume__)).

Added @AnastasiaStulova for help with the OpenCL questions. I would love to avoid adding `omp_assume` if possible.

> It should be noted that, without the omp_assume spelling, it would be impossible to use this attribute in C without running into -pedantic warnings; we could consider supporting [[omp::assume]] in C23, though.

My guess is that the OpenMP folks haven't gotten around to rebasing on top of C23 yet and that's really the only thing holding back supporting `[[]]` spellings in C with OpenMP. @alexey-bataev, should we enable OpenMP attribute spellings whenever double square bracket attributes are enabled?

> From what I can tell, no-one except libclc is actually using this attribute? At least on github, the only matches I’ve found for __attribute__((assume("omp are in LLVM and various forks thereof. Given that it’s not particularly widely used, I don’t think removal without deprecation would be that big of a deal in this case, though if you think that that’s a non-option, then I’d instead suggest deprecating it and removing it in a later version of Clang.

This matches my searching around on https://sourcegraph.com/search?q=context:global+__attribute__%28%28assume%28%22omp+-file:.*test.*+-file:.*llvm.*+-file:.*%5C.rst&patternType=keyword&sm=0 so I think removal without deprecation may be reasonable unless @alexey-bataev knows of something we're missing.

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