erichkeane 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?
The one option we HAVE for this sort of thing is the `annotate` and `annotate_type` attributes, which can provide (IIRC) arbitrary string attributes into LLVM-IR. 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
