wsmoses added a comment. Just to preface these comments -- this is work in progress and not intended to go in as is / without discussion (but happily is indeed inviting discussion).
In D63845#1561983 <https://reviews.llvm.org/D63845#1561983>, @lebedev.ri wrote: > In D63845#1561793 <https://reviews.llvm.org/D63845#1561793>, @jdoerfert wrote: > > > In D63845#1560605 <https://reviews.llvm.org/D63845#1560605>, @aaron.ballman > > wrote: > > > > > 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? > > > > > > > > > With "normal" you mean something like `__attribute__((noescape))`? We don't > > have them for all attributes, I doubt we want to but I might be wrong. > > > That is precisely the question. > What is the motivation for exposing such LLVM-specific low-level unstable > implementation detail? There's a couple of potential use cases for this -- most of which are more for LLVM developers than end users. The primary driver behind this is a research/GSOC project to try propagating information learned in LLVM analysis back into augmented headers. I've also personally run into situations where I've been either trying create new attributes for LLVM or generating test cases for optimizations that require specific LLVM attributes and otherwise don't exist with clang's existing frontend. >>>> How is versioning expected to be handled? New attribute vs old clang, and >>>> vice versa. >> >> Unknown attributes are not necessarily a problem, they should compile fine >> ignoring the attribute, or am I wrong? > > I don't know, that's why i'm asking. Off the top of my head, there's a couple of ways we could imagine dealing with versioning: - We could have the equivalent of the LLVM/Clang version included as part of the attribute (e.g. something like `__attribute__((llvm7_arg(a, "nocapture")))`) - We could let nonexistent attributes simply slide into extraneous string attributes. In its current form it will look for an enum attribute if one exists and if not create a string attribute. I don't believe that extraneous string attributes would cause any harm -- but correct me if I'm wrong. - We could separate string attributes from enum attributes and raise errors if an enum attribute doesn't exist. This doesn't cover semantic changes, but provides more information than creating it as an extra string attribute (at cost of possible compiler error for the user). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63845/new/ https://reviews.llvm.org/D63845 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
