[clang] [Clang][HTO] Add clang attribute for propagating llvm-level information (PR #83059)

Erich Keane via cfe-commits cfe-commits at lists.llvm.org
Tue Feb 27 07:30:23 PST 2024


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


More information about the cfe-commits mailing list