[llvm-branch-commits] [clang] [Clang][CodeGen] Move AllocToken pass to backend LTO phases (PR #169360)

[Marco Elver via llvm-branch-commits]

melver wrote:

> Why AllocToken is a problem for other optimization? Can PGHO be aware of AllocToken?

PGHO rewrites in `LibCallSimplifier::optimizeNew` rely in LibFunc identification. If we rewrite them it won't recognize them.

PGHO could be made aware of AllocToken if we teach it to recognize the ABI, but I think it's generally infeasible; perhaps checking for the `__alloc_token` prefix is easy, but we also need to support 2 calling conventions. On the other hand PGHO rewrites are relatively limited (few hot_cold_t variants) and its rewrites are part of known LibFuncs, which AllocToken already recognizes as-is.

Similarly, it's going to be easier for other similar optimizations that rely on specific known LibCall identification.

> AllocToken replies on metadata, later it applied, less the quality.

I agree, but I think if we can make it work in the LTO backend it will be simpler for other optimizations incl. PGHO.

> Rather than having different ways to inject this pass for the different LTO backend pipelines, and for distributed vs in process ThinLTO, and also rather than passing internal options to the linker driver which we're trying to get away from, can the pass be added unconditionally from the PassBuilder::build*LTODefaultPipeline in the correct location and guarded by something in the IR? In fact, looking at the AllocToken pass, it already appears to be a noop without the necessary attributes and intrinsics. Can the mode also be passed down in the IR via an attribute or at least a module flag to simplify the enablement?

I can look at the module flag, maybe that can work to derive the options. 

https://github.com/llvm/llvm-project/pull/169360