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
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.