wsmoses wrote: @AaronBallman @erichkeane, do you have any suggestions for paths forward, for use cases where it is guaranteed that the attribute is valid and the user (or perhaps more specifically, another Clang-tool) needs to provide information to LLVM through Clang AST/source.
For example, I have a clang plugin that should apply specific LLVM (string) attributes to functions. Unfortunately, without a way to modify codegen in the clang plugin, this prevents this workflow from working without significant hacks. Presently those "hacks" are essentially making a new global variable that takes the function and an LLVM pass that parses those globals into attributes -- which is quite poor, and has issues for templates, etc. In the case of the original research study that inspired this (HTO), we built an experimental LTO replacement tool that emitted headers that contained the derived LLVM attributes that were missing for the source and found significant speedup as a result. This has even more of the implementation detail requirement that you mention, but again has the guarantee that it is emitted by the same clang. Would this be permissible as a hidden attribute, or perhaps it takes an additional argument for the LLVM version, and errs if the version doesn't match the present compiler? https://github.com/llvm/llvm-project/pull/83059 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
