Some targets have different defaults. This patch defers initialization of TargetOptions so that a future patch can pass TargetOptions to InitTargetOptionsFromCodeGenFlags
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
1,150 ms | linux > libarcher.parallel::parallel-nosuppression.c |
Event Timeline
llvm/tools/llc/llc.cpp | ||
---|---|---|
429 | Thanks for the patch. Doing it after codegen::InitTargetOptionsFromCodeGenFlags gets called looks like an aftermath, and there could be tools other than llc called codegen::InitTargetOptionsFromCodeGenFlags and they should do this dance, but they do not. |
llvm/tools/llc/llc.cpp | ||
---|---|---|
429 | Mentioned in the description: "This patch defers initialization of TargetOptions so that a future patch can pass TargetOptions to InitTargetOptionsFromCodeGenFlags" The InitTargetOptionsFromCodeGenFlags change will be yours:) I'll change Triple &TheTriple to const Triple &TheTriple. |
llvm/tools/llc/llc.cpp | ||
---|---|---|
429 | Sounds good. Let me give it a try in that direction. |
Thanks for the patch.
An ideal solution would be actually pass the Triple as argument to the codegen::InitTargetOptionsFromCodeGenFlags. So that InitTargetOptionsFromCodeGenFlags could always initialize the correct default value depending on the target triple if an explicit setting is not present.
And we would do something similar to this:
Options.DataSections = codegen::getExplicitDataSections.getValueOr(Triple.hasDefaultDataSections());
Doing it after codegen::InitTargetOptionsFromCodeGenFlags gets called looks like an aftermath, and there could be tools other than llc called codegen::InitTargetOptionsFromCodeGenFlags and they should do this dance, but they do not.