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 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
