From 69e75ae695d9ef1360a2a1fbefd6e0e0456c3f7b Mon Sep 17 00:00:00 2001 From: Matt Arsenault Date: Thu, 18 Jun 2020 09:00:16 -0400 Subject: CodeGen: Don't lazily construct MachineFunctionInfo This fixes what I consider to be an API flaw I've tripped over multiple times. The point this is constructed isn't well defined, so depending on where this is first called, you can conclude different information based on the MachineFunction. For example, the AMDGPU implementation inspected the MachineFrameInfo on construction for the stack objects and if the frame has calls. This kind of worked in SelectionDAG which visited all allocas up front, but broke in GlobalISel which hasn't visited any of the IR when arguments are lowered. I've run into similar problems before with the MIR parser and trying to make use of other MachineFunction fields, so I think it's best to just categorically disallow dependency on the MachineFunction state in the constructor and to always construct this at the same time as the MachineFunction itself. A missing feature I still could use is a way to access an custom analysis pass on the IR here. --- llvm/lib/CodeGen/MachineModuleInfo.cpp | 1 + 1 file changed, 1 insertion(+) (limited to 'llvm/lib/CodeGen/MachineModuleInfo.cpp') diff --git a/llvm/lib/CodeGen/MachineModuleInfo.cpp b/llvm/lib/CodeGen/MachineModuleInfo.cpp index 23d55a5df9f5..7a5a6c294ecf 100644 --- a/llvm/lib/CodeGen/MachineModuleInfo.cpp +++ b/llvm/lib/CodeGen/MachineModuleInfo.cpp @@ -118,6 +118,7 @@ MachineFunction &MachineModuleInfo::getOrCreateMachineFunction(Function &F) { // No pre-existing machine function, create a new one. const TargetSubtargetInfo &STI = *TM.getSubtargetImpl(F); MF = new MachineFunction(F, TM, STI, NextFnNum++, *this); + MF->initTargetMachineFunctionInfo(STI); // Update the set entry. I.first->second.reset(MF); } else { -- cgit v1.2.3