search for: branchfolderpass

...und out about that one too. As mentioned in MachineFunctionPass.h:42 a MachineFunctionPass that overrides getAnalysisUsage() _has_ to call MachineFunctionPass::getAnalysisUsage() because there MachineFunctionAnalysis is required and preserved. The problem mentioned by me was in a newly created BranchFolderPass::getAnalysisUsage() method which did not call MachineFunctionPass::getAnalysisUsage(). Andi -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-r90454.passmanager.patch Type: text/x-diff Size: 801 bytes Desc: not available URL: <http://lists.llvm.org/piperm...

On Fri, Nov 20, 2009 at 6:54 AM, Andreas Neustifter <astifter-llvm at gmx.at> wrote: > > If I use  AU.addRequired<ProfileInfo>() in SelectionDAGISel.cpp the > wrong ProfileInfo is used. It uses the "No ProfileInfo" implementation > if ProfileInfo but not the one from ProfileInfoLoaderPass. (Which is > immediately discarded after creation.) > You need to

...ses run after register allocation (ordered and categorized according to how they appear in lib/CodeGen/Passes.cpp): OptimizedRegAlloc: (run only if there is a RegAllocPass, which is not true for wasm) StackSlotColoring PostRAMachineLICM ShrinkWrap PrologEpilogInserter Machine late optimization: BranchFolderPass TailDuplicate MachineCopyPropagation PostRAScheduler ExpandPostRAPseudos ImplicitNullChecks (optional) PostMachineScheduler or PostRAScheduler GC: GCMachineCodeAnalysis GC info printer Block Placement: MachineBlockPlacement MachineBlockPlacementStats FuncletLayout StackMapLiveness LiveDebugV...

...tegorized according to how they appear in > lib/CodeGen/Passes.cpp): > > OptimizedRegAlloc: (run only if there is a RegAllocPass, which is not true > for wasm) > StackSlotColoring > PostRAMachineLICM > ShrinkWrap > PrologEpilogInserter > Machine late optimization: > BranchFolderPass > TailDuplicate > MachineCopyPropagation > PostRAScheduler > ExpandPostRAPseudos > ImplicitNullChecks (optional) > PostMachineScheduler or PostRAScheduler > GC: > GCMachineCodeAnalysis > GC info printer > Block Placement: > MachineBlockPlacement > MachineB...

...fea70, MF=...) at /work/llvm/trunk/llvm/lib/CodeGen/BranchFolding.cpp:972 #15 0x089298c2 in llvm::BranchFolder::OptimizeFunction (this=0xbfffea70, MF=..., tii=0x92cf50c, tri=0x92cf528, mmi=0x92f1228) at /work/llvm/trunk/llvm/lib/CodeGen/BranchFolding.cpp:208 #16 0x08929150 in (anonymous namespace)::BranchFolderPass::runOnMachineFunction (this=0x9309d28, MF=...) at /work/llvm/trunk/llvm/lib/CodeGen/BranchFolding.cpp:91 #17 0x08820b79 in llvm::MachineFunctionPass::runOnFunction (this=0x9309d28, F=...) at /work/llvm/trunk/llvm/lib/CodeGen/MachineFunctionPass.cpp:33 #18 0x08b7a49a in llvm::FPPassManager::runOnFun...

...asses.cpp): >>> >>> OptimizedRegAlloc: (run only if there is a RegAllocPass, which is not true for wasm) >>> StackSlotColoring >>> PostRAMachineLICM >>> ShrinkWrap >>> PrologEpilogInserter >>> Machine late optimization: >>> BranchFolderPass >>> TailDuplicate >>> MachineCopyPropagation >>> PostRAScheduler >>> ExpandPostRAPseudos >>> ImplicitNullChecks (optional) >>> PostMachineScheduler or PostRAScheduler >>> GC: >>> GCMachineCodeAnalysis >>> GC info...

To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way. Problems when using virtregs throughout the backend until emit time: - The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs - VirtRegs are assumed to have a definition,