[WIP] TargetMachine Hook for Module Metadata

[lenary]

Summary

This patch attempts to add a target-overridable hook for allowing module metadata
to override TargetMachine options, especially during LTO.

The new hook is called TargetMachine::resetTargetDefaultOptions and takes the
llvm::Module so that the module metadata can be read with the API provided
by llvm::Module.

It is not clear that this patch handles LTO correctly at the moment.

This patch relates to D72245 and D72246 and the discussion in
http://lists.llvm.org/pipermail/llvm-dev/2020-January/138151.html

[tejohnson]

I'm not sure if ThinLTOCodeGenerator.cpp and LTOBackend.cpp were intentionally left out due to the LTO concerns mentioned in the description?

Note if we are just passing in the Module and updating the TM based on that, it wouldn't hit the threading issue I mentioned in D72245, but neither would you get the proper aggregation/checking across ThinLTO'ed modules.

llvm/include/llvm/Target/TargetMachine.h

194

Is there a way to enforce this? Otherwise I foresee fragility. E.g. what if this method set a flag on the TM indicating that we have updated it properly from the Module, and TargetMachine::createDataLayout() asserted that this flag was set?

llvm/lib/Target/TargetMachine.cpp

52

Looks like DefaultOptions is const, so override methods wouldn't be able to change it.

54

Can you clarify how M will be used - will a follow on patch set the MCOptions.ABIName from the Module? Note in the meantime you will likely need to mark this with an LLVM_ATTRIBUTE_UNUSED.

[khchen]

I think putting the resetTargetDefaultOptions after instance of TargetMachine is too late.
for example:
ppc and mips compute the TargetABI in XXXXTargetMachine constructor. In addition , mips compute the DataLayout with target ABI in TargetMachine constructor.

[khchen]

In D72624#1818605, @khchen wrote:

I think putting the resetTargetDefaultOptions after instance of TargetMachine is too late.
for example:
ppc and mips compute the TargetABI in XXXXTargetMachine constructor. In addition , mips compute the DataLayout with target ABI in TargetMachine constructor.

Sorry, I didn't notice the resetTargetDefaultOptions is a virtual function, so the backend need to care this issue themselves if they want take this approach.
I think this approach is better than D72245.

[lenary]

In D72624#1817464, @tejohnson wrote:

Thank you for your feedback! It has been very helpful.

I'm not sure if ThinLTOCodeGenerator.cpp and LTOBackend.cpp were intentionally left out due to the LTO concerns mentioned in the description?

Mostly left out because I wasn't sure how to attack them. I've got an update to this patch which I'm testing right now and it looks much better. I will post that imminently.

Note if we are just passing in the Module and updating the TM based on that, it wouldn't hit the threading issue I mentioned in D72245, but neither would you get the proper aggregation/checking across ThinLTO'ed modules.

Ok, right, so I think I know what else this patch needs to do. At the moment, I think the ModFlagBehavior for module flags are not being checked during ThinLTO. I think this is something that has to be checked for compatibility in ThinLTOCodeGenerator::addModule (like the triple is checked for compatibility).

I see that the checking behaviour is in IRMover, but I don't think ThinLTO uses that, and I don't feel familiar enough with ThinLTO to be sure.

The update to my patch will not address this part of ThinLTO.

llvm/lib/Target/TargetMachine.cpp

52

I contemplated making DefaultOptions non-const, but the truth is lots of subclasses of TargetMachine set new values to Options in the subclass initializers.

So the intention now is that the hook can just set more values on Options.

54

Yeah, the idea is that a target-specific subclass will override this method, and extract module flags from M, which they can use to set values in Options.

In the case of RISC-V, the RISCVTargetMachine will use the target-abi module flag to set Options.MCOptions.ABIName. I hope that it might also be used by other backends like Mips, but I think their case is already handled by LLVM at the moment.

[lenary]

Address some review feedback.

This patch remains incomplete with regards to module flags and ThinLTO.

[merge_guards_bot]

Unit tests: pass. 61807 tests passed, 0 failed and 781 were skipped.

clang-tidy: unknown.

clang-format: pass.

Build artifacts: diff.json, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

[tejohnson]

In D72624#1820281, @lenary wrote:

In D72624#1817464, @tejohnson wrote:

Thank you for your feedback! It has been very helpful.

I'm not sure if ThinLTOCodeGenerator.cpp and LTOBackend.cpp were intentionally left out due to the LTO concerns mentioned in the description?

Mostly left out because I wasn't sure how to attack them. I've got an update to this patch which I'm testing right now and it looks much better. I will post that imminently.

Note if we are just passing in the Module and updating the TM based on that, it wouldn't hit the threading issue I mentioned in D72245, but neither would you get the proper aggregation/checking across ThinLTO'ed modules.

Ok, right, so I think I know what else this patch needs to do. At the moment, I think the ModFlagBehavior for module flags are not being checked during ThinLTO. I think this is something that has to be checked for compatibility in ThinLTOCodeGenerator::addModule (like the triple is checked for compatibility).

And LTO::addModule (just to add confusion, there are two LTO APIs, ThinLTOCodeGenerator is the old one and LTO is the new one, the latter being used by lld and the gold plugin).

I had mentioned using LTO::addModule to do the checking in the other patch, but there is a complication I should mention:

I see that the checking behaviour is in IRMover, but I don't think ThinLTO uses that, and I don't feel familiar enough with ThinLTO to be sure.

The ThinLTO "link", which is where the modules are added serially, does not read IR, only the summaries, which are linked together into a large index used to drive ThinLTO whole program analysis. So you can't really read the module flags directly during addModule, they need to be propagated via the summary flags. The ThinLTO backends which are subsequently fired off in parallel do read IR. In those backends, depending on the results of the ThinLTO analysis phase, we may use IRMover to link in ("import) functions from other modules. At that point, the module flags from any modules that backend is importing from will be combined and any errors due to conficting values will be issued.

Thinking through this some more, rather than attempting to fully validate the consistency of the module flags across all modules in ThinLTO mode, just rely on some checking when we merge subsections of the IR in the ThinLTO backends during this importing, which will happen automatically. This is presumably where the checking is desirable anyway (in terms of the cases you are most interested in catching with ThinLTO, because the IR is getting merged). Note that unlike in the full LTO case, where the IR is merged before you create the TM, in the ThinLTO case the TM will be created before any of this cross-module importing (partial IR merging), so with your patch presumably it will just use whatever module flag is on that original Module for it's corresponding ThinLTO backend. But since it sounds like any difference in these module flags is an error, it will just get flagged a little later but not affect how the TM is set up in the correct case. Does that sound reasonable?

The update to my patch will not address this part of ThinLTO.

I'll take a look through your patch later today or tomorrow, but it may be just fine from the above perspective.

[dblaikie]

(just a general comment that this code review should be only in service of the design discussion happening on llvm-dev - please don't approve/commit this without closing out the design discussion there if there are actionable conclusions from this review)

[tejohnson]

In D72624#1820598, @dblaikie wrote:

(just a general comment that this code review should be only in service of the design discussion happening on llvm-dev - please don't approve/commit this without closing out the design discussion there if there are actionable conclusions from this review)

Got it, I will just look at from the LTO perspective. The target ABI specifics I haven't followed very closely and are not really my expertise.

[lenary]

One thing to note about my patch, above: I have not made the TargetMachine DataLayout non-const, but I wanted to ensure that this might be possible in future, which is why calling initializeOptionsWithModuleMetadata must be done before the first call to createDataLayout. At the moment, the RISC-V ABI data layouts are based only on riscv32 vs riscv64, not the target-abi metadata (all riscv32 ABIs use the same data layout, all riscv64 ABIs use the same data layout), but I know Mips has more complex logic for computing their data layout based on their ABI.

In D72624#1820580, @tejohnson wrote:

The ThinLTO "link", which is where the modules are added serially, does not read IR, only the summaries, which are linked together into a large index used to drive ThinLTO whole program analysis. So you can't really read the module flags directly during addModule, they need to be propagated via the summary flags. The ThinLTO backends which are subsequently fired off in parallel do read IR. In those backends, depending on the results of the ThinLTO analysis phase, we may use IRMover to link in ("import) functions from other modules. At that point, the module flags from any modules that backend is importing from will be combined and any errors due to conficting values will be issued.

This has been a very helpful explanation of ThinLTO.

Thinking through this some more, rather than attempting to fully validate the consistency of the module flags across all modules in ThinLTO mode, just rely on some checking when we merge subsections of the IR in the ThinLTO backends during this importing, which will happen automatically. This is presumably where the checking is desirable anyway (in terms of the cases you are most interested in catching with ThinLTO, because the IR is getting merged). Note that unlike in the full LTO case, where the IR is merged before you create the TM, in the ThinLTO case the TM will be created before any of this cross-module importing (partial IR merging), so with your patch presumably it will just use whatever module flag is on that original Module for it's corresponding ThinLTO backend. But since it sounds like any difference in these module flags is an error, it will just get flagged a little later but not affect how the TM is set up in the correct case. Does that sound reasonable?

That does sound reasonable. I want errors to be reported, which it sounds like will happen, even if it is only "lazily" when using ThinLTO.

At some point in the future the ThinLTO summaries might want to gain knowledge of the module flags, which would help with eager error reporting (i.e., ThinLTO telling the user that two modules are incompatible before it does any analysis), but I think that is a step too far for this patch.

I shall look at making a patch with the RISC-V specific behaviour that @khchen and I intend implement on top of this, and then running more tests (including doing llvm test-suite runs with each kind of LTO enabled).

[tejohnson]

From an LTO perspective, this seems fine for the reasons we discussed here. I looked through the patch and have a few comments.

clang/lib/CodeGen/BackendUtil.cpp

818

Also needed in EmitAssemblyWithNewPassManager. Maybe it should be moved into CreateTargetMachine which would cover both cases.

I'm not sure if this was already discussed - but is there a reason why this can't be done in Target::createTargetMachine()? Is it not possible to ensure it is called once we have the Module available and pass that in? That would centralize this handling and seems cleaner overall.

llvm/include/llvm/Target/TargetMachine.h

157

Do you want to also ensure that createDataLayout is only called iff initializeOptionsWithModuleMetadata was previously called? That would need to make this a tri-state, or use 2 bools. Then you could assert here that the other routine was already called at this point, which would help avoid missing calls (like the one I pointed out above), possibly due to future code drift.

192

Should this be private so that it can only be called via initializeOptionsWithModuleMetadata?

[khchen]

Hi @lenary, I added a PoC patch D78035 to complete ThinLTO based on this patch.

There is also a missed hook in ParallelCG.cpp

@@ -28,6 +28,7 @@ static void codegen(Module *M, llvm::raw_pwrite_stream &OS,
                     function_ref<std::unique_ptr<TargetMachine>()> TMFactory,
                     CodeGenFileType FileType) {
   std::unique_ptr<TargetMachine> TM = TMFactory();
+  TM->initializeOptionsWithModuleMetadata(*M);
   legacy::PassManager CodeGenPasses;
   if (TM->addPassesToEmitFile(CodeGenPasses, OS, nullptr, FileType))
     report_fatal_error("Failed to setup codegen");

I'm not sure passing Module in Target::createTargetMachine() is a good or not,
because maybe the module flag will changed in next time on JIT compilation scenario?

clang/lib/CodeGen/BackendUtil.cpp

void EmitAssemblyHelper::EmitAssembly(BackendAction Action,
 
   bool UsesCodeGen = (Action != Backend_EmitNothing &&
                       Action != Backend_EmitBC &&
                       Action != Backend_EmitLL);
   CreateTargetMachine(UsesCodeGen);
 
   if (UsesCodeGen && !TM)
     return;
-  if (TM)
+
+  if (TM) {
+    TM->initializeOptionsWithModuleMetadata(*TheModule);
     TheModule->setDataLayout(TM->createDataLayout());
+  }
 
   legacy::PassManager PerModulePasses;
   PerModulePasses.add(
       createTargetTransformInfoWrapperPass(getTargetIRAnalysis()));
 
   legacy::FunctionPassManager PerFunctionPasses(TheModule);
   PerFunctionPasses.add(
       createTargetTransformInfoWrapperPass(getTargetIRAnalysis()));

clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp

static std::string OptLLVM(const std::string &IR, CodeGenOpt::Level OLvl) {
   const TargetOptions Options = InitTargetOptionsFromCodeGenFlags();
   std::string E;
   const Target *TheTarget = TargetRegistry::lookupTarget(MArch, ModuleTriple, E);
   TargetMachine *Machine =
       TheTarget->createTargetMachine(M->getTargetTriple(), getCPUStr(),
                                      getFeaturesStr(), Options, getRelocModel(),
                                      getCodeModel(), OLvl);
   std::unique_ptr<TargetMachine> TM(Machine);
+  TM->initializeOptionsWithModuleMetadata(*M);
   setFunctionAttributes(getCPUStr(), getFeaturesStr(), *M);
 
   legacy::PassManager Passes;
   
   Passes.add(new TargetLibraryInfoWrapperPass(ModuleTriple));
   Passes.add(createTargetTransformInfoWrapperPass(TM->getTargetIRAnalysis()));
 
   LLVMTargetMachine &LTM = static_cast<LLVMTargetMachine &>(*TM);

lldb/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptExpressionOpts.cpp

if (changed_module) {
     if (log) {
       LLDB_LOGF(log, "%s - Changing RS target triple to '%s'", __FUNCTION__,
                 real_triple.str().c_str());
       LLDB_LOGF(
           log, "%s - Changing RS datalayout to '%s'", __FUNCTION__,
           target_machine->createDataLayout().getStringRepresentation().c_str());
     }
     module.setTargetTriple(real_triple);
+    target_machine->initializeOptionsWithModuleMetadata(module);
     module.setDataLayout(target_machine->createDataLayout());
   }
   return changed_module;
 }
 
 char RenderScriptRuntimeModulePass::ID = 0;
 
 namespace lldb_private {

llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl08.rst

 We're now ready to configure our module, to specify the target and
 data layout. This isn't strictly necessary, but the `frontend
 performance guide <../Frontend/PerformanceTips.html>`_ recommends
 this. Optimizations benefit from knowing about the target and data
 layout.
 
 .. code-block:: c++
 
-  TheModule->setDataLayout(TargetMachine->createDataLayout());
-  TheModule->setTargetTriple(TargetTriple);   
-  
+  TheModule->setTargetTriple(TargetTriple);
+  TargetMachine->initializeOptionsWithModuleMetadata(*TheModule);
+  TheModule->setDataLayout(TargetMachine->createDataLayout());
 Emit Object Code
 ================
 
 We're ready to emit object code! Let's define where we want to write
 our file to:
 
 .. code-block:: c++
 

llvm/examples/Kaleidoscope/Chapter8/toy.cpp

int main() {
   auto CPU = "generic";
   auto Features = "";
 
   TargetOptions opt;
   auto RM = Optional<Reloc::Model>();
   auto TheTargetMachine =
       Target->createTargetMachine(TargetTriple, CPU, Features, opt, RM);
 
+  TheTargetMachine->initializeOptionsWithModuleMetadata(*TheModule);
   TheModule->setDataLayout(TheTargetMachine->createDataLayout());
 
   auto Filename = "output.o";
   std::error_code EC;
   raw_fd_ostream dest(Filename, EC, sys::fs::OF_None);
 
   if (EC) {
     errs() << "Could not open file: " << EC.message();

llvm/include/llvm/LTO/legacy/ThinLTOCodeGenerator.h

 struct TargetMachineBuilder {
   Triple TheTriple;
   std::string MCpu;
   std::string MAttr;
   TargetOptions Options;
   Optional<Reloc::Model> RelocModel;
   CodeGenOpt::Level CGOptLevel = CodeGenOpt::Aggressive;
 
-  std::unique_ptr<TargetMachine> create() const;
+  std::unique_ptr<TargetMachine> create(Module &TheModule) const;
 };
 
 /// This class define an interface similar to the LTOCodeGenerator, but adapted
 /// for ThinLTO processing.
 /// The ThinLTOCodeGenerator is not intended to be reuse for multiple
 /// compilation: the model is that the client adds modules to the generator and
 /// ask to perform the ThinLTO optimizations / codegen, and finally destroys the
 /// codegenerator.

llvm/include/llvm/Target/TargetMachine.h

protected: // Can only create subclasses.
   std::unique_ptr<const MCAsmInfo> AsmInfo;
   std::unique_ptr<const MCRegisterInfo> MRI;
   std::unique_ptr<const MCInstrInfo> MII;
   std::unique_ptr<const MCSubtargetInfo> STI;
 
   unsigned RequireStructuredCFG : 1;
   unsigned O0WantsFastISel : 1;
 
+private:
+  mutable unsigned OptionsCanBeInitalizedFromModule : 1;
+
 public:
   const TargetOptions DefaultOptions;
   mutable TargetOptions Options;
 
   TargetMachine(const TargetMachine &) = delete;
   void operator=(const TargetMachine &) = delete;
   virtual ~TargetMachine();
 
public:
   /// This method returns a pointer to the specified type of
   /// TargetSubtargetInfo.  In debug builds, it verifies that the object being
   /// returned is of the correct type.
   template <typename STC> const STC &getSubtarget(const Function &F) const {
     return *static_cast<const STC*>(getSubtargetImpl(F));
   }
 
   /// Create a DataLayout.
-  const DataLayout createDataLayout() const { return DL; }
+  const DataLayout createDataLayout() const {
+    OptionsCanBeInitalizedFromModule = false;
+    return DL;
+  }
 
   /// Test if a DataLayout if compatible with the CodeGen for this target.
   ///
   /// The LLVM Module owns a DataLayout that is used for the target independent
   /// optimizations and code generation. This hook provides a target specific
   /// check on the validity of this DataLayout.
   bool isCompatibleDataLayout(const DataLayout &Candidate) const {
     return DL == Candidate;
public:
   unsigned getProgramPointerSize() const {
     return DL.getPointerSize(DL.getProgramAddressSpace());
   }
 
   unsigned getAllocaPointerSize() const {
     return DL.getPointerSize(DL.getAllocaAddrSpace());
   }
 
+  /// Target hook for updating this TargetMachine's Options based
+  // on the provided module metadata.
+  virtual void
+  setTargetOptionsWithModuleMetadata(const Module &M LLVM_ATTRIBUTE_UNUSED) {}
+
+  /// This method ensures that `setTargetOptionsWithModuleMetadata` is
+  // called, and ensures that is called before `createDataLayout` so that
+  // Options set from module metadata are modified as early as possible
+  // before they are used.
+  void initializeOptionsWithModuleMetadata(const Module &M);
+
   /// Reset the target options based on the function's attributes.
   // FIXME: Remove TargetOptions that affect per-function code generation
   // from TargetMachine.
   void resetTargetOptions(const Function &F) const;
 
   /// Return target specific asm information.
   const MCAsmInfo *getMCAsmInfo() const { return AsmInfo.get(); }
 

llvm/lib/LTO/LTOBackend.cpp

RelocModel =
         M.getPICLevel() == PICLevel::NotPIC ? Reloc::Static : Reloc::PIC_;
 
   Optional<CodeModel::Model> CodeModel;
   if (Conf.CodeModel)
     CodeModel = *Conf.CodeModel;
   else
     CodeModel = M.getCodeModel();
 
-  return std::unique_ptr<TargetMachine>(TheTarget->createTargetMachine(
+  std::unique_ptr<TargetMachine> TM(TheTarget->createTargetMachine(
       TheTriple, Conf.CPU, Features.getString(), Conf.Options, RelocModel,
       CodeModel, Conf.CGOptLevel));
+
+  TM->initializeOptionsWithModuleMetadata(M);
+
+  return TM;
 }
 
 static void runNewPMPasses(const Config &Conf, Module &Mod, TargetMachine *TM,
                            unsigned OptLevel, bool IsThinLTO,
                            ModuleSummaryIndex *ExportSummary,
                            const ModuleSummaryIndex *ImportSummary) {
   Optional<PGOOptions> PGOOpt;
   if (!Conf.SampleProfile.empty())

llvm/lib/LTO/LTOCodeGenerator.cpp

if (MCpu.empty() && Triple.isOSDarwin()) {
     else if (Triple.getArch() == llvm::Triple::x86)
       MCpu = "yonah";
     else if (Triple.getArch() == llvm::Triple::aarch64 ||
              Triple.getArch() == llvm::Triple::aarch64_32)
       MCpu = "cyclone";
   }
 
   TargetMach = createTargetMachine();
+  TargetMach->initializeOptionsWithModuleMetadata(*MergedModule);
   return true;
 }
 
 std::unique_ptr<TargetMachine> LTOCodeGenerator::createTargetMachine() {
   return std::unique_ptr<TargetMachine>(MArch->createTargetMachine(
       TripleStr, MCpu, FeatureStr, Options, RelocModel, None, CGOptLevel));
 }
 

llvm/lib/LTO/ThinLTOCodeGenerator.cpp

 void ThinLTOCodeGenerator::crossReferenceSymbol(StringRef Name) {
   // FIXME: At the moment, we don't take advantage of this extra information,
   // we're conservatively considering cross-references as preserved.
   //  CrossReferencedSymbols.insert(Name);
   PreservedSymbols.insert(Name);
 }
 
 // TargetMachine factory
-std::unique_ptr<TargetMachine> TargetMachineBuilder::create() const {
+std::unique_ptr<TargetMachine>
+TargetMachineBuilder::create(Module &TheModule) const {
   std::string ErrMsg;
   const Target *TheTarget =
       TargetRegistry::lookupTarget(TheTriple.str(), ErrMsg);
   if (!TheTarget) {
     report_fatal_error("Can't load target for this Triple: " + ErrMsg);
   }
 
   // Use MAttr as the default set of features.
   SubtargetFeatures Features(MAttr);
   Features.getDefaultSubtargetFeatures(TheTriple);
   std::string FeatureStr = Features.getString();
 
-  return std::unique_ptr<TargetMachine>(
+  std::unique_ptr<TargetMachine> TM(
       TheTarget->createTargetMachine(TheTriple.str(), MCpu, FeatureStr, Options,
                                      RelocModel, None, CGOptLevel));
+
+  TM->initializeOptionsWithModuleMetadata(TheModule);
+
+  return TM;
 }
 
 /**
  * Produce the combined summary index from all the bitcode files:
  * "thin-link".
  */
 std::unique_ptr<ModuleSummaryIndex> ThinLTOCodeGenerator::linkCombinedIndex() {
   std::unique_ptr<ModuleSummaryIndex> CombinedIndex =

 
 /**
  * Perform post-importing ThinLTO optimizations.
  */
 void ThinLTOCodeGenerator::optimize(Module &TheModule) {
   initTMBuilder(TMBuilder, Triple(TheModule.getTargetTriple()));
 
   // Optimize now
-  optimizeModule(TheModule, *TMBuilder.create(), OptLevel, Freestanding,
-                 nullptr);
+  optimizeModule(TheModule, *TMBuilder.create(TheModule), OptLevel,
+                 Freestanding, nullptr);
 }
 
 /// Write out the generated object file, either from CacheEntryPath or from
 /// OutputBuffer, preferring hard-link when possible.
 /// Returns the path to the generated file in SavedObjectsDirectoryPath.
 std::string
 ThinLTOCodeGenerator::writeGeneratedObject(int count, StringRef CacheEntryPath,
                                            const MemoryBuffer &OutputBuffer) {
for (auto &Mod : Modules) {
         LLVMContext Context;
         Context.setDiscardValueNames(LTODiscardValueNames);
 
         // Parse module now
         auto TheModule = loadModuleFromInput(Mod.get(), Context, false,
                                              /*IsImporting*/ false);
 
         // CodeGen
-        auto OutputBuffer = codegenModule(*TheModule, *TMBuilder.create());
+        auto OutputBuffer =
+            codegenModule(*TheModule, *TMBuilder.create(*TheModule));
         if (SavedObjectsDirectoryPath.empty())
           ProducedBinaries[count] = std::move(OutputBuffer);
         else
           ProducedBinaryFiles[count] =
               writeGeneratedObject(count, "", *OutputBuffer);
       }, count++);
     }
 
for (auto IndexCount : ModulesOrdering) {
                                              /*IsImporting*/ false);
 
         // Save temps: original file.
         saveTempBitcode(*TheModule, SaveTempsDir, count, ".0.original.bc");
 
         auto &ImportList = ImportLists[ModuleIdentifier];
         // Run the main process now, and generates a binary
         auto OutputBuffer = ProcessThinLTOModule(
-            *TheModule, *Index, ModuleMap, *TMBuilder.create(), ImportList,
-            ExportList, GUIDPreservedSymbols,
+            *TheModule, *Index, ModuleMap, *TMBuilder.create(*TheModule),
+            ImportList, ExportList, GUIDPreservedSymbols,
             ModuleToDefinedGVSummaries[ModuleIdentifier], CacheOptions,
             DisableCodeGen, SaveTempsDir, Freestanding, OptLevel, count);
 
         // Commit to the cache (if enabled)
         CacheEntry.write(*OutputBuffer);
 
         if (SavedObjectsDirectoryPath.empty()) {
           // We need to generated a memory buffer for the linker.

llvm/lib/Target/TargetMachine.cpp

 //
 
 TargetMachine::TargetMachine(const Target &T, StringRef DataLayoutString,
                              const Triple &TT, StringRef CPU, StringRef FS,
                              const TargetOptions &Options)
     : TheTarget(T), DL(DataLayoutString), TargetTriple(TT), TargetCPU(CPU),
       TargetFS(FS), AsmInfo(nullptr), MRI(nullptr), MII(nullptr), STI(nullptr),
       RequireStructuredCFG(false), O0WantsFastISel(false),
-      DefaultOptions(Options), Options(Options) {}
+      OptionsCanBeInitalizedFromModule(true), DefaultOptions(Options),
+      Options(Options) {}
 
 TargetMachine::~TargetMachine() = default;
 
 bool TargetMachine::isPositionIndependent() const {
   return getRelocationModel() == Reloc::PIC_;
 }
 
+void TargetMachine::initializeOptionsWithModuleMetadata(const Module &M) {
+  assert(
+      OptionsCanBeInitalizedFromModule &&
+      "setOptionsWithModuleMetadata cannot be called after createDataLayout");
+
+  setTargetOptionsWithModuleMetadata(M);
+}
+
 /// Reset the target options based on the function's attributes.
 // FIXME: This function needs to go away for a number of reasons:
 // a) global state on the TargetMachine is terrible in general,
 // b) these target options should be passed only on the function
 //    and not on the TargetMachine (via TargetOptions) at all.
 void TargetMachine::resetTargetOptions(const Function &F) const {
 #define RESET_OPTION(X, Y)                                                     \
   do {                                                                         \

llvm/lib/Target/TargetMachineC.cpp

static LLVMBool LLVMTargetMachineEmit(LLVMTargetMachineRef T, LLVMModuleRef M,
                                       char **ErrorMessage) {
   TargetMachine* TM = unwrap(T);
   Module* Mod = unwrap(M);
 
   legacy::PassManager pass;
 
   std::string error;
 
+  TM->initializeOptionsWithModuleMetadata(*Mod);
   Mod->setDataLayout(TM->createDataLayout());
 
   CodeGenFileType ft;
   switch (codegen) {
     case LLVMAssemblyFile:
       ft = CGFT_AssemblyFile;
       break;
     default:

llvm/tools/llc/llc.cpp

static int compileModule(char **argv, LLVMContext &Context) {
 
   // If we don't have a module then just exit now. We do this down
   // here since the CPU/Feature help is underneath the target machine
   // creation.
   if (SkipModule)
     return 0;
 
   assert(M && "Should have exited if we didn't have a module!");
+
+  // Initialise target default options from module metadata
+  Target->initializeOptionsWithModuleMetadata(*M);
+
   if (FloatABIForCalls != FloatABI::Default)
     Options.FloatABIType = FloatABIForCalls;
 
   // Figure out where we are going to send the output.
   std::unique_ptr<ToolOutputFile> Out =
       GetOutputStream(TheTarget->getName(), TheTriple.getOS(), argv[0]);
   if (!Out) return 1;
 

llvm/tools/llvm-isel-fuzzer/llvm-isel-fuzzer.cpp

extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
   auto M = parseAndVerify(Data, Size, Context);
   if (!M) {
     errs() << "error: input module is broken!\n";
     return 0;
   }
 
   // Set up the module to build for our target.
   M->setTargetTriple(TM->getTargetTriple().normalize());
+  TM->initializeOptionsWithModuleMetadata(*M);
   M->setDataLayout(TM->createDataLayout());
 
   // Build up a PM to do instruction selection.
   legacy::PassManager PM;
   TargetLibraryInfoImpl TLII(TM->getTargetTriple());
   PM.add(new TargetLibraryInfoWrapperPass(TLII));
   raw_null_ostream OS;
   TM->addPassesToEmitFile(PM, OS, nullptr, CGFT_Null);

llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp

if (!M) {
     errs() << "error: input module is broken!\n";
     return 0;
   }
 
   // Set up target dependant options
   //
 
   M->setTargetTriple(TM->getTargetTriple().normalize());
+  TM->initializeOptionsWithModuleMetadata(*M);
   M->setDataLayout(TM->createDataLayout());
   setFunctionAttributes(TM->getTargetCPU(), TM->getTargetFeatureString(), *M);
 
   // Create pass pipeline
   //
 
   PassBuilder PB(TM.get());
 

llvm/tools/opt/opt.cpp

Machine = GetTargetMachine(ModuleTriple, CPUStr, FeaturesStr, Options);
              ModuleTriple.getArchName() != "") {
     errs() << argv[0] << ": unrecognized architecture '"
            << ModuleTriple.getArchName() << "' provided.\n";
     return 1;
   }
 
   std::unique_ptr<TargetMachine> TM(Machine);
 
+  if (TM)
+    TM->initializeOptionsWithModuleMetadata(*M);
+
   // Override function attributes based on CPUStr, FeaturesStr, and command line
   // flags.
   setFunctionAttributes(CPUStr, FeaturesStr, *M);
 
   // If the output is set to be emitted to standard out, and standard out is a
   // console, print out a warning message and refuse to do it.  We don't
   // impress anyone by spewing tons of binary goo to a terminal.
   if (!Force && !NoOutput && !AnalyzeOnly && !OutputAssembly)

llvm/unittests/CodeGen/AArch64SelectionDAGTest.cpp

TM = std::unique_ptr<LLVMTargetMachine>(static_cast<LLVMTargetMachine*>(
                                CodeGenOpt::Aggressive)));
     if (!TM)
       return;
 
     SMDiagnostic SMError;
     M = parseAssemblyString(Assembly, SMError, Context);
     if (!M)
       report_fatal_error(SMError.getMessage());
+    TM->initializeOptionsWithModuleMetadata(*M);
     M->setDataLayout(TM->createDataLayout());
 
     F = M->getFunction("f");
     if (!F)
       report_fatal_error("F?");
 
     MachineModuleInfo MMI(TM.get());
 

llvm/unittests/CodeGen/GlobalISel/GISelMITest.h

static std::unique_ptr<LLVMTargetMachine> createTargetMachine() {
   TargetOptions Options;
   return std::unique_ptr<LLVMTargetMachine>(
       static_cast<LLVMTargetMachine *>(T->createTargetMachine(
           "AArch64", "", "", Options, None, None, CodeGenOpt::Aggressive)));
 }
 
 static std::unique_ptr<Module> parseMIR(LLVMContext &Context,
                                         std::unique_ptr<MIRParser> &MIR,
-                                        const TargetMachine &TM,
-                                        StringRef MIRCode, const char *FuncName,
+                                        TargetMachine &TM, StringRef MIRCode,
+                                        const char *FuncName,
                                         MachineModuleInfo &MMI) {
   SMDiagnostic Diagnostic;
   std::unique_ptr<MemoryBuffer> MBuffer = MemoryBuffer::getMemBuffer(MIRCode);
   MIR = createMIRParser(std::move(MBuffer), Context);
   if (!MIR)
     return nullptr;
 
   std::unique_ptr<Module> M = MIR->parseIRModule();
   if (!M)
     return nullptr;
 
+  TM.initializeOptionsWithModuleMetadata(*M);
   M->setDataLayout(TM.createDataLayout());
 
   if (MIR->parseMachineFunctions(*M, MMI))
     return nullptr;
 
   return M;
 }
 
 static std::pair<std::unique_ptr<Module>, std::unique_ptr<MachineModuleInfo>>
-createDummyModule(LLVMContext &Context, const LLVMTargetMachine &TM,
+createDummyModule(LLVMContext &Context, LLVMTargetMachine &TM,
                   StringRef MIRFunc) {
   SmallString<512> S;
   StringRef MIRString = (Twine(R"MIR(
 ---
 ...
 name: func
 registers:
   - { id: 0, class: _ }

llvm/unittests/ExecutionEngine/Orc/CMakeLists.txt

 
 set(LLVM_LINK_COMPONENTS
   Core
   ExecutionEngine
   Object
   OrcError
   OrcJIT
   Passes
   RuntimeDyld
   Support
+  Target
   native
   )
 
 add_llvm_unittest(OrcJITTests
   CoreAPIsTest.cpp
   IndirectionUtilsTest.cpp
   GlobalMappingLayerTest.cpp
   JITTargetMachineBuilderTest.cpp

llvm/unittests/ExecutionEngine/Orc/RemoteObjectLayerTest.cpp

MockObjectLayer::ObjectPtr createTestObject() {
   OrcNativeTarget::initialize();
   auto TM = std::unique_ptr<TargetMachine>(EngineBuilder().selectTarget());
 
   if (!TM)
     return nullptr;
 
   LLVMContext Ctx;
   ModuleBuilder MB(Ctx, TM->getTargetTriple().str(), "TestModule");
+  TM->initializeOptionsWithModuleMetadata(*MB.getModule());
   MB.getModule()->setDataLayout(TM->createDataLayout());
   auto *Main = MB.createFunctionDecl(
       FunctionType::get(Type::getInt32Ty(Ctx),
                         {Type::getInt32Ty(Ctx),
                          Type::getInt8PtrTy(Ctx)->getPointerTo()},
                         false),
       "main");
   Main->getBasicBlockList().push_back(BasicBlock::Create(Ctx));

llvm/unittests/MI/LiveIntervalTest.cpp

std::unique_ptr<LLVMTargetMachine> createTargetMachine() {
 
   TargetOptions Options;
   return std::unique_ptr<LLVMTargetMachine>(static_cast<LLVMTargetMachine*>(
       T->createTargetMachine("AMDGPU", "", "", Options, None, None,
                              CodeGenOpt::Aggressive)));
 }
 
 std::unique_ptr<Module> parseMIR(LLVMContext &Context,
-    legacy::PassManagerBase &PM, std::unique_ptr<MIRParser> &MIR,
-    const LLVMTargetMachine &TM, StringRef MIRCode, const char *FuncName) {
+                                 legacy::PassManagerBase &PM,
+                                 std::unique_ptr<MIRParser> &MIR,
+                                 LLVMTargetMachine &TM, StringRef MIRCode,
+                                 const char *FuncName) {
   SMDiagnostic Diagnostic;
   std::unique_ptr<MemoryBuffer> MBuffer = MemoryBuffer::getMemBuffer(MIRCode);
   MIR = createMIRParser(std::move(MBuffer), Context);
   if (!MIR)
     return nullptr;
 
   std::unique_ptr<Module> M = MIR->parseIRModule();
   if (!M)
     return nullptr;
 
+  TM.initializeOptionsWithModuleMetadata(*M);
   M->setDataLayout(TM.createDataLayout());
 
   MachineModuleInfoWrapperPass *MMIWP = new MachineModuleInfoWrapperPass(&TM);
   if (MIR->parseMachineFunctions(*M, MMIWP->getMMI()))
     return nullptr;
   PM.add(MMIWP);
 
   return M;

mlir/lib/Conversion/GPUToCUDA/ConvertKernelFuncToCubin.cpp

if (target == nullptr) {
       emitError(loc, "cannot initialize target triple");
       return {};
     }
     targetMachine.reset(
         target->createTargetMachine(triple.str(), "sm_35", "+ptx60", {}, {}));
   }
 
   // Set the data layout of the llvm module to match what the ptx target needs.
+  targetMachine->initializeOptionsWithModuleMetadata(llvmModule);
   llvmModule.setDataLayout(targetMachine->createDataLayout());
 
   auto ptx = translateModuleToPtx(llvmModule, *targetMachine);
 
   return cubinGenerator(ptx, loc, name);
 }
 
 StringAttr GpuKernelToCubinPass::translateGPUModuleToCubinAnnotation(

mlir/lib/ExecutionEngine/ExecutionEngine.cpp

bool ExecutionEngine::setupTargetTriple(Module *llvmModule) {
   std::string errorMessage;
   auto target = llvm::TargetRegistry::lookupTarget(targetTriple, errorMessage);
   if (!target) {
     errs() << "NO target: " << errorMessage << "\n";
     return true;
   }
   std::unique_ptr<llvm::TargetMachine> machine(
       target->createTargetMachine(targetTriple, "generic", "", {}, {}));
-  llvmModule->setDataLayout(machine->createDataLayout());
   llvmModule->setTargetTriple(targetTriple);
+  machine->initializeOptionsWithModuleMetadata(*llvmModule);
+  llvmModule->setDataLayout(machine->createDataLayout());
   return false;
 }
 
 static std::string makePackedFunctionName(StringRef name) {
   return "_mlir_" + name.str();
 }
 
 // For each function in the LLVM module, define an interface function that wraps