================
@@ -1114,8 +1115,7 @@ void TargetPassConfig::addMachinePasses() {
// feature takes precedence. This means functions eligible for
// basic-block-sections optimizations (`=all`, or `=list=` with function
// included in the list profile) will get that optimization instead.
- if (TM->Options.EnableMachineFunctionSplitter ||
- Opts.enable_split_machine_functions)
+ if (SplitFunctions)
----------------
MattPD wrote:
Could we account for libLTO options passed after generator creation? I compiled
a PGO-profiled `foo` with this sequence: create the generator, add the module,
preserve `foo`, pass the splitting option to
`lto_codegen_debug_options_array()`, and call `lto_codegen_compile()`. Before
this PR, that sequence emits `foo.cold` with `-enable-split-machine-functions`.
With this PR, libLTO accepts `-function-splitting=all`, but the output lacks
`foo.cold` and the pass trace omits the splitter.
libLTO copies `TargetOptions` before parsing those options. Calling
`lto_set_debug_options()` before generator creation restores splitting. Should
`-function-splitting` also take effect through
`lto_codegen_debug_options_array()`, or should the migration note require
`lto_set_debug_options()` before generator creation?
https://github.com/llvm/llvm-project/pull/226575
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
