search for: machinelicm

What are the correct target description side effect flags for instructions which may trap (e.g. divide / remainder)? The divide instruction in my backend currently has no flags set. I've enabled the MachineLICM pass and it's causing a miscompilation by hoisting a divide by zero instruction out of the loop. Clearly this pass needs to be made aware that this is not safe. The current test in the MachineLICM is as follows: // Ignore stuff that we obviously can't hoist. if (TID.mayStore() || TI...

...ht the above patch would work. It didn't. What it turned out to be is: ./lib/CodeGen/LLVMTargetMachine.cpp:41 EnableLICM("machine-licm", cl::init(false), cl::Hidden, cl::desc("Perform loop-invariant code motion on machine code")); and ./lib/CodeGen/MachineLICM.cpp:156: static RegisterPass<MachineLICM> X("machine-licm", "Machine Loop Invariant Code Motion"); Both are defining a command line option with the same name. I'm I the only person who links both at the same time? :-( My suggestion: change the name of one or the oth...

Thanks for the tip! I looked into it and it looks like the problem as of SVN HEAD is that the lui and ori instructions in Mips are considered cheap (1-cycle def-use latency) by MachineLICM::IsCheapInstruction(), but are not trivially materializable because their register operands are not always available. This makes MachineLICM::IsProfitableToHoist() return false, preventing the hoist even though MachineLICM::IsLoopInvariantInst() returns true. The comment in IsProfitableToHois...

I'm trying to create the Machine LICM pass and I have this defined: class VISIBILITY_HIDDEN MachineLICM : public MachineFunctionPass { ... public: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<MachineLoopInfo>(); AU.addRequired<MachineDominatorTree>(); } ... }; But when I go to use it: bool Machi...

...gt; What it turned out to be is: > > ./lib/CodeGen/LLVMTargetMachine.cpp:41 > EnableLICM("machine-licm", > cl::init(false), cl::Hidden, > cl::desc("Perform loop-invariant code motion on machine > code")); > > and > ./lib/CodeGen/MachineLICM.cpp:156: > static RegisterPass<MachineLICM> > X("machine-licm", "Machine Loop Invariant Code Motion"); > > Both are defining a command line option with the same name. I'm I the > only person who links both at the same time? :-( > > My suggestion: c...

...-simplify -scalar-evolution -loop-simplify -iv-users -loop-reduce -gc-lowering -unreachableblockelim -codegenprepare -stack-protector -preverify -domtree -verify -loops -branch-prob -expand-isel-pseudos -tailduplication -opt-phis -localstackalloc -dead-mi-elimination -machinedomtree -machine-loops -machinelicm -machine-cse -machine-sink -peephole-opts -unreachable-mbb-elimination -livevars -phi-node-elimination -twoaddressinstruction -processimpdefs -slotindexes -liveintervals -livedebugvars -simple-register-coalescing -calcspillweights -livestacks -virtregmap -edge-bundles -spill-code-placement -stack-s...

Yes machine-licm can and should hoist constant materialization instructions out of the loop. If it's not doing that, it's probably because the target is not modeling the instruction correctly. I would walk through MachineLICM::IsLoopInvariantInst() in the debugger to figure it out. You can also try compiling the same bitcode for a target like ARM or X86 as a comparison. Evan On Mar 7, 2012, at 10:38 AM, Matt Johnson wrote: > Hi All, > I work on a backend for a target similar to Mips, where large > immed...

Hi:    I want to do some optimization on MachineLoop. So I want to get MachineLoopInfo from MachineFunction. I reference MachineLICM.cpp. So I try to write a pass in Target/mytarget directory. I find there is Error. llvm/include/llvm/PassAnalysisSupport.h:198: AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const [with AnalysisType = llvm::MachineLoopInfo]: Assertion `ResultPass && "getAnalysis*(...

...re -rewrite-symbols -verify-di -stack-protector -verify -domtree -loops -branch-prob -machinedomtree -expand-isel-pseudos -tailduplication -opt-phis -machinedomtree -slotindexes -stack-coloring -localstackalloc -dead-mi-elimination -machinedomtree -machine-loops -machine-trace-metrics -early-ifcvt -machinelicm -machine-cse -machinepostdomtree -machine-block-freq -machine-sink -peephole-opts -dead-mi-elimination -processimpdefs -unreachable-mbb-elimination -livevars -machinedomtree -machine-loops -phi-node-elimination -twoaddressinstruction -slotindexes -liveintervals -simple-register-coalescing -misched...

...olution -loop-simplify -iv-users -loop-reduce -gc-lowering > -unreachableblockelim -codegenprepare -stack-protector -preverify > -domtree -verify -loops -branch-prob -expand-isel-pseudos > -tailduplication -opt-phis -localstackalloc -dead-mi-elimination > -machinedomtree -machine-loops -machinelicm -machine-cse -machine-sink > -peephole-opts -unreachable-mbb-elimination -livevars > -phi-node-elimination -twoaddressinstruction -processimpdefs > -slotindexes -liveintervals -livedebugvars -simple-register-coalescing > -calcspillweights -livestacks -virtregmap -edge-bundles > -spil...

Hi All, I work on a backend for a target similar to Mips, where large immediates are loaded into registers with 2 instructions, 1 to load the MSBits and 1 to load the LSBits. I've noticed a recurring pattern where, despite low register pressure, these constants will be rematerialized in every iteration of a loop, rather than being hoisted. Here's an example using the

...> > > There are a couple of issues here. One, InstCombine's job is the move the > IR toward a reasonable canonical form. It is doing that here, and I think > that's the right thing to do. However, the problem you point out is a > general one. Can you please explain why the MachineLICM pass is not able to > hoist the redundant parts of the addressing computation out of the loop? We > might also want to adjust for this in CodeGenPrep (CGP already has > addressing-mode aware GEP splitting logic, although not quite for this > case). > > Hi Hal, MachineLICM is not...

...alias a merged alloca. 538 MMO->setValue(0); 539 continue; 540 } The attached patch makes the code above less conservative. It avoids clearing a mem operand if its underlying value is a PseudoSourceValue and PseudoSourceValue::isConstant returns true. This enables MachineLICM to hoist loads from GOT out of a loop (see test case in stackcoloring-test.patch). Please review. Question: Why does it need to clear a mem operand if the underlying object is not an AllocaInst? I am not sure if I understand the reason for this. -------------- next part -------------- An HTML att...

Hi everyone, The MachineLICM pass has a heuristic such that, even in low-register-pressure situations, it will refuse to hoist "cheap" instructions out of loops. By default, when an itinerary is available, this means that all of the defined operands are available in at most 1 cycle. ARM overrides this, and provides t...

...hat was a bit more aggressive and will hoist cheap instructions if they don't increase register pressure, but it doesn't help us in this case because lui/ori are a pair of dependent ori instructions. There is a chicken-and-egg problem where neither can be hoisted without the other, and MachineLICM is not aggressive enough to recognize chains of dependent, loop-invariant cheap instructions. At the time, the advice was to implement a PseudoInstruction for lui+ori and lower it in a C++ pass, as is done in ARM (see MOVi32imm in ARMInstrInfo.td and ARMExpandPseudoInsts.cpp). I did this for my...

...-tbaa-scoped-noalias -vector-combine -verify -write-bitcode not contained in multi O3 (count=67) -attributor -block-freq-loop-simplify -branch-folder -break-false-deps -callsite-splitting-ipsccp -codegenprepare -consthoist -dead-mi-elimination -detect-dead-lanes -early-ifcvt -early-machinelicm -early-tailduplication -expandmemcmp -greedy -interleaved-access -iv-users -lazy-block-freq-opt-remark-emitter -livedebugvars -liveintervals -liveregmatrix -livestacks -livevars -loop-reduce -loop-simplify-lcssa-verification -lrshrink -machine-block-freq -machine-combiner -machine-...

...gt;> -branch-folder >> >> -break-false-deps >> >> -callsite-splitting-ipsccp >> >> -codegenprepare >> >> -consthoist >> >> -dead-mi-elimination >> >> -detect-dead-lanes >> >> -early-ifcvt >> >> -early-machinelicm >> >> -early-tailduplication >> >> -expandmemcmp >> >> -greedy >> >> -interleaved-access >> >> -iv-users >> >> -lazy-block-freq-opt-remark-emitter >> >> -livedebugvars >> >> -liveintervals >> >&...

Hello I am not sure I understand the logic for merging GEPs in InstructionCombining.cpp: static bool shouldMergeGEPs(GEPOperator &GEP, GEPOperator &Src) { // If this GEP has only 0 indices, it is the same pointer as // Src. If Src is not a trivial GEP too, don't combine // the indices. if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() &&

...alias a merged alloca. 538 MMO->setValue(0); 539 continue; 540 } The attached patch makes the code above less conservative. It avoids clearing a mem operand if its underlying value is a PseudoSourceValue and PseudoSourceValue::isConstant returns true. This enables MachineLICM to hoist loads from GOT out of a loop (see test case in stackcoloring-test.patch). Please review. Question: Why does it need to clear a mem operand if the underlying object is not an AllocaInst? I am not sure if I understand the reason for this. -------------- next part -------------- An HTML att...

...y dependent on the target's instruction set. Do we have any pass hoisting the constant loading out of the (inner) loops after isel ? I guess this could be beneficial for most targets --- assuming the pass does not increase the register pressure to some unreasonnable level. Yes; see lib/CodeGen/MachineLICM.cpp. -Eli