[PATCH] D63845: [WIP] Create a clang attribute that lets users specify LLVM attributes

[Aaron Ballman via Phabricator via llvm-commits]

aaron.ballman added a reviewer: aaron.ballman.
aaron.ballman added a comment.

In D63845#1559995 <https://reviews.llvm.org/D63845#1559995>, @lebedev.ri wrote:

> What's the target use-case here? What can't be solved with normal attributes?
>  I wonder if this should go to cfe+llvm -dev lists first, it's kinda intrusive.
>  I also wonder if all these should cause a clang diagnostic, at least under `-Wall`.
>  How is versioning expected to be handled? New attribute vs old clang, and vice versa.


Also, we already have the `annotate` attribute for passing information through to LLVM. Why do we need four different ways to do this?



================
Comment at: clang/include/clang/Basic/Attr.td:1638
+def LLVMFN : InheritableAttr {
+  let Spellings = [GCC<"LLVMFN">];
+  let Args = [StringArgument<"AttrName">];
----------------
This is not a GCC attribute, so this needs a different spelling. Also, the all-caps names are a bit obnoxious, so we may want to pick a different name.

Do you envision these being attributes users will write in production code? What kind of guarantees do they have about the stability of the attribute interfaces that LLVM provides? For instance, are we promising that LLVM attributes will remain backwards compatible (e.g., won't be removed or renamed)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63845/new/

https://reviews.llvm.org/D63845