search for: machinecse

Hi, My target has a special configuration register that many instructions read implicitly, configuring for example if an add instruction should saturate at over/underflow or not. Now, I have a problem where the MachineCSE removes a setting of this configuration register in a basic block, because MachineCSE::isPhysDefTriviallyDead can't find any uses of it in the basic block where it's defined. Similar to other special physical registers, e.g the stack pointer, this configuration register is marked as &q...

..._______________________________ > From: Jim Grosbach <grosbach at apple.com> >To: Johannes Birgmeier <e0902998 at student.tuwien.ac.at> >Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >Sent: Monday, 19 December 2011 10:33 PM >Subject: Re: [LLVMdev] Stop MachineCSE on certain instructions > >Hi Johannes, > >You may be interested in the (very) recently added explicit instruction bundle support. For an example of their usage, have a look at the ARM backend's IT-block (Thumb2 predication support) pass, which uses them to tie instructions togethe...

...Thanks. > Girish. > > From: Jim Grosbach <grosbach at apple.com> > To: Johannes Birgmeier <e0902998 at student.tuwien.ac.at> > Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Monday, 19 December 2011 10:33 PM > Subject: Re: [LLVMdev] Stop MachineCSE on certain instructions > > Hi Johannes, > > You may be interested in the (very) recently added explicit instruction bundle support. For an example of their usage, have a look at the ARM backend's IT-block (Thumb2 predication support) pass, which uses them to tie instructions toge...

...for a backend and have a complicated instruction bundle (3 instructions) that has to be executed like a single block (meaning: if the first instruction is executed, all three have to be executed to obtain the result, though not necessarily without other instructions in between). Unfortunately, MachineCSE gets in the way sometimes and rips it apart. Is there a way to stop CSE from doing its thing (common subexpression elimination) for certain instructions? I've already tried glueing (gluing?) them together, but that doesn't seem to make a difference. Regards, Johannes Birgmeier

...ave a complicated instruction bundle (3 > instructions) that has to be executed like a single block (meaning: if > the first instruction is executed, all three have to be executed to > obtain the result, though not necessarily without other instructions in > between). Unfortunately, MachineCSE gets in the way sometimes and rips > it apart. > > Is there a way to stop CSE from doing its thing (common subexpression > elimination) for certain instructions? > > I've already tried glueing (gluing?) them together, but that doesn't > seem to make a difference. &...

...sbach <grosbach at apple.com> >To: girish gulawani <girishvg at yahoo.com> >Cc: Johannes Birgmeier <e0902998 at student.tuwien.ac.at>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >Sent: Wednesday, 21 December 2011 12:41 AM >Subject: Re: [LLVMdev] Stop MachineCSE on certain instructions > >Hi Girish, > >Sorry, but I'm afraid I don't understand your question. Can you elaborate a bit? > >-Jim > >On Dec 19, 2011, at 9:12 PM, girish gulawani wrote: > >> >> Hello Jim. >> Just out of curiosity, won't such...

...sbach <grosbach at apple.com> >To: girish gulawani <girishvg at yahoo.com> >Cc: Johannes Birgmeier <e0902998 at student.tuwien.ac.at>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >Sent: Wednesday, 21 December 2011 11:30 PM >Subject: Re: [LLVMdev] Stop MachineCSE on certain instructions > > >Ah, OK. I think I understand much better now. Thanks! You shouldn't need bundles for that sort of thing. A custom lowering or a fancy pattern should be sufficient, depending on the details of how your target is defined. > > >For patterns, looks at...

...h <grosbach at apple.com> > To: girish gulawani <girishvg at yahoo.com> > Cc: Johannes Birgmeier <e0902998 at student.tuwien.ac.at>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Wednesday, 21 December 2011 12:41 AM > Subject: Re: [LLVMdev] Stop MachineCSE on certain instructions > > Hi Girish, > > Sorry, but I'm afraid I don't understand your question. Can you elaborate a bit? > > -Jim > > On Dec 19, 2011, at 9:12 PM, girish gulawani wrote: > > > > > Hello Jim. > > Just out of curiosity, won...

...ave a complicated instruction bundle (3 > instructions) that has to be executed like a single block (meaning: if > the first instruction is executed, all three have to be executed to > obtain the result, though not necessarily without other instructions in > between). Unfortunately, MachineCSE gets in the way sometimes and rips > it apart. > > Is there a way to stop CSE from doing its thing (common subexpression > elimination) for certain instructions? > > I've already tried glueing (gluing?) them together, but that doesn't > seem to make a difference. &...

...d instruction bundle (3 >> instructions) that has to be executed like a single block (meaning: if >> the first instruction is executed, all three have to be executed to >> obtain the result, though not necessarily without other instructions in >> between). Unfortunately, MachineCSE gets in the way sometimes and rips >> it apart. >> >> Is there a way to stop CSE from doing its thing (common subexpression >> elimination) for certain instructions? >> >> I've already tried glueing (gluing?) them together, but that doesn't >>...

...;> Depth=1 >> cmpl $2, %edi >> jbe .LBB0_4 >> # BB#5: # %sw.bb6 >> ret >> >> the second 'cmpl' is totally redundant, which pass is >> (or would be) in charge of removing it? > > MachineCSE should be in charge of zapping it. Hi Chris, I had a look into MachineCSE, but it looks like MBB-oriented. The above problem is an inter-block one. Also MCSE seems to perform value numbering on virtual/physical registers, which does not map very well to status register bits that are implicitly de...

Hi Eli, I know the pass that fails, it is MachineCSE. It stack overflows because there are too many recursive calls to processBlock (line 362 of lib/CodeGen/MachineCSE.cpp). But the recursion is here on purpose, and I am sure there are other places where LLVM makes recursive calls. Or is recursion forbidden in LLVM, and explicitly stated to be so? C...

On Oct 13, 2010, at 11:22 AM, Gabor Greif wrote: > Hi Chris, > > I had a look into MachineCSE, but it looks like MBB-oriented. > The above problem is an inter-block one. Also MCSE seems > to perform value numbering on virtual/physical registers, which > does not map very well to status register bits that are implicitly > defined. > Any chance to recast this issue as a target-...

Hello Devs, Machine Instruction verifier pass always validates Live variable info associated with MachineInstr along with other checks. Please consider following scenario (w.r.t bugZilla 32583) 1/ MachineCSE pass may prohibit optimising out a common sub-expression for instruction using physical registers by looking at the LiveIn info of successor basic blocks. 2/ Which means we need Live Variables analysis to happen prior to executing MachineCSE. 3/ Live variable analysis associates Kill/def informat...

On Tue, Apr 13, 2010 at 9:33 AM, nicolas geoffray <nicolas.geoffray at gmail.com> wrote: > Hi Eli, > I know the pass that fails, it is MachineCSE. It stack overflows because > there are too many recursive calls to processBlock (line 362 of > lib/CodeGen/MachineCSE.cpp). But the recursion is here on purpose, and I am > sure there are other places where LLVM makes recursive calls. Or is > recursion forbidden in LLVM, and explicitly...

Hi all, I am slowly working on a SwitchInst optimizer (http://llvm.org/PR8125) and now I am running into a deficiency of the x86 peephole optimizer (or jump-threader?). Here is what I get: andl $3, %edi je .LBB0_4 # BB#2: # %nz # in Loop: Header=BB0_1 Depth=1 cmpl $2, %edi

...# in Loop: Header=BB0_1 > Depth=1 > cmpl $2, %edi > jbe .LBB0_4 > # BB#5: # %sw.bb6 > ret > > the second 'cmpl' is totally redundant, which pass is > (or would be) in charge of removing it? MachineCSE should be in charge of zapping it. -Chris

...s.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hello Devs, > > Machine Instruction verifier pass always validates Live variable info associated with MachineInstr along with other checks. > > Please consider following scenario (w.r.t bugZilla 32583) > > 1/ MachineCSE pass may prohibit optimising out a common sub-expression for instruction using physical registers > by looking at the LiveIn info of successor basic blocks. > > 2/ Which means we need Live Variables analysis to happen prior to executing MachineCSE. > > 3/ Live variable analysis a...

...LLVM :: CodeGen/X86/2008-02-08-LoadFoldingBug.ll LLVM :: CodeGen/X86/2009-09-10-SpillComments.ll LLVM :: CodeGen/X86/2010-02-19-TailCallRetAddrBug.ll LLVM :: CodeGen/X86/2010-04-13-AnalyzeBranchCrash.ll LLVM :: CodeGen/X86/2011-10-11-SpillDead.ll LLVM :: CodeGen/X86/2011-10-12-MachineCSE.ll LLVM :: CodeGen/X86/2011-11-09-FoldImpDefs.ll LLVM :: CodeGen/X86/Atomics-64.ll LLVM :: CodeGen/X86/fold-pcmpeqd-2.ll 17 of these tests started failing with the commit r145975, "First chunk of MachineInstr bundle support." on 12/6/2011. I've verified that the tests pa...

...at -O0. Since this results in more code in the XCore backend that needs to be maintained over time I'd rather explore other options first. Is there a view on which of the following approaches is better in general when two nodes with debug locations are merged because of CSE (either in the MachineCSE pass or because of the CSEMap in the SelectionDAG): 1) Use the DebugLoc of either of the pair of nodes (chosen arbitrarily). 2) Throw away the line number information on the merged node since it is not possible to preserve the information that operation is associated with multiple lines. The c...