search for: lowerselect

Hi, A number of transforms are actually independent, so here's a partial fix. I updated the dependencies in a cluster of transforms: LowerSwitch, Mem2Reg, LowerSelect, LowerAllocations, UnifyFunctionExitNodes. The patch has been tested, but not extensively. PassManager doesn't complain, and the result of a test pass that requires all these (except for LowerAllocations) together works fine. Domagoj ***************************** PATCH BEGIN ***************...

...n passes and noticed a few things. In particular, I found three passes in the documentation that I can't seem to find any code for. Where these removed? Lower GC intrinsics, for GCless code generators (-lowergc) Correlated Expression Elimination (-cee) Lower select instructions to branches (-lowerselect) Additionally, I found the following passes for which no documentation was present: createGVExtractionPass() createStructRetPromotionPass() createStripDeadPrototypesPass() createJumpThreadingPass() createMemCpyOptPass() createLoopDeletionPass() createCodeGenPreparePass() From what I saw i...

...y target (embedded processor, which is a "not so direct" successor of Z80 family of processors) does not support SELECT, so I was looking for a workaround. First I was thinking about expanding it into conditional flow with branching, but then I have found that there exists a pass called LowerSelect already. I added in the getAnalysisUsage of my DAGtoDAGSel class (derived from SelectionDAGSel) as a required analysis. After that, there are no more SELECT instructions passed to my code selector, which is what I wanted. Is it a correct to do it this way? Anyhow, I have a very strong impression...

...gt; successor > > of Z80 family of processors) does not support SELECT, so I was > looking > > for a workaround. > > > > First I was thinking about expanding it into conditional flow with > > branching, but then I have found that there exists a pass called > > LowerSelect already. > > > > I added in the getAnalysisUsage of my DAGtoDAGSel class (derived > from > > SelectionDAGSel) as a required analysis. After that, there are no > more > > SELECT instructions passed to my code selector, which is what I > wanted. > > Is it a corr...

...hitecture without conditional moves. Which way can we lower select? As we know there was the special pass a long time ago, but it was deleted. commit c3591a0d48ce045bbf5ae0d78a41f3dae4bb99db Author: Chris Lattner <sabre at nondot.org> Date:   Tue Feb 19 07:49:17 2008 +0000     remove the LowerSelect pass.  The last client was the old Sparc backend, which is long dead by now.     llvm-svn: 47323 The problem is that if we use this pass we lose some useful special optimizing cases for selects, e.g. replacing it by min/max. Does anyone have some experience with such architecture? We're...

...backend for an example. > > I actually tried it first. But then if, I remember correctly, SELECT > nodes were expanded into something using SELECT_CC, which is also not > supported on my target. Basically, only conditional branches are > supported. Therefore I thought about using the LowerSelect pass. But > I'll try again this evening. May be I was doing something wrong. > > What should be the result of expanding SELECT? Some sort of > IF-THEN-ELSE flow? Check out how the sparc or powerpc backends handle this. They lower to a select_cc pseudo-op that expands to an if/th...

...sses in the documentation that I > can't seem to find any code for. Where these removed? > Lower GC intrinsics, for GCless code generators (-lowergc) Yes; this pass at least has been removed. > Correlated Expression Elimination (-cee) > Lower select instructions to branches (-lowerselect) > > Additionally, I found the following passes for which no > documentation was present: > createGVExtractionPass() > createStructRetPromotionPass() > createStripDeadPrototypesPass() > createJumpThreadingPass() > createMemCpyOptPass() > createLoopDeletionPass() &...

..., which is a "not so direct" successor > of Z80 family of processors) does not support SELECT, so I was looking > for a workaround. > > First I was thinking about expanding it into conditional flow with > branching, but then I have found that there exists a pass called > LowerSelect already. > > I added in the getAnalysisUsage of my DAGtoDAGSel class (derived from > SelectionDAGSel) as a required analysis. After that, there are no more > SELECT instructions passed to my code selector, which is what I wanted. > Is it a correct to do it this way? You can add the l...

On Mon, 2 Oct 2006, Roman Levenstein wrote: >>> Wouldn't it be possible and even more clean to have just one >>> description like (I use a pseudo-description here): >>> >>> def MOVrr : I<0x88, MRMDestReg, (ops (GR8|GR16|GR32) :$dst, >>> (i8mem|i16mem|i32mem):$src), >>> "mov{b} {$src, $dst|$dst, $src}", []>,

...c), e, x), (select (x == c), c, e) -> select (x == c), x, e) where the <c> is an integer constant. The reason for this change is that : on x86, conditional-move-from-constant needs two instructions; however, conditional-move-from-register need only one instruction. While the LowerSELECT() sounds to be the most convenient place for this optimization, it turns out to be a bad place.The reason is that by replacing the constant <c> with a symbolic value, it obscure some instruction-combining opportunities which would otherwise be very easy to spot. For that reason, I have to...

Hi Chris, Thanks a lot for your answer! Chris Lattner wrote: >> 1. Why does X86 instruction set description provide different >> descriptions for the same instructions, which differ only in the size >> of operands? >> E.g. >> >> def MOV8rm : I<0x8A, MRMSrcMem, (ops GR8 :$dst, i8mem :$src), >> "mov{b} {$src, $dst|$dst, $src}",

...those platforms. The ARM conditions seem to sorta-kinda use predicated instructions (the subject of my next mail). The x86 implementation seems closer to what I want. On closer inspection though, it turns out that the x86 implementation ALWAYS emits a new comparison instruction (in LowerBRCOND and LowerSELECT). baldrick encouraged me to submit bug #3761 (http://llvm.org/bugs/show_bug.cgi?id=3761) as this is suboptimal. My question is how do I achieve my goal? How do I get llvm to recognize the fact that my ALU instructions set the flag register? Thanks for your help, someguy

...those platforms. The ARM conditions seem to sorta-kinda use predicated instructions (the subject of my next mail). The x86 implementation seems closer to what I want. On closer inspection though, it turns out that the x86 implementation ALWAYS emits a new comparison instruction (in LowerBRCOND and LowerSELECT). baldrick encouraged me to submit bug #3761 (http://llvm.org/bugs/show_bug.cgi?id=3761) as this is suboptimal. My question is how do I achieve my goal? How do I get llvm to recognize the fact that my ALU instructions set the flag register? Thanks for your help, someguy

...hat I >> can't seem to find any code for. Where these removed? >> Lower GC intrinsics, for GCless code generators (-lowergc) > > Yes; this pass at least has been removed. > >> Correlated Expression Elimination (-cee) >> Lower select instructions to branches (-lowerselect) These two were also removed. Dan

...ting. The second, pass-doc.diff is mostly a yank-put job and updates Passes.html as follows. I've removed the following passes from the documentation: Lower GC intrinsics, for GCless code generators (-lowergc) Correlated Expression Elimination (-cee) Lower select instructions to branches (-lowerselect) lowers packed operations to operations on smaller packed datatypes (-lower-packed) (I didn't report the last one in my initial posting, though I had noticed it was missing). I've added the following passes to the documentation: > createStructRetPromotionPass() > createStripDeadP...

...gt; > I actually tried it first. But then if, I remember correctly, > SELECT > > nodes were expanded into something using SELECT_CC, which is also > not > > supported on my target. Basically, only conditional branches are > > supported. Therefore I thought about using the LowerSelect pass. > But > > I'll try again this evening. May be I was doing something wrong. > > > > What should be the result of expanding SELECT? Some sort of > > IF-THEN-ELSE flow? > > Check out how the sparc or powerpc backends handle this. They lower > to a >...

Hi, if I want to know how switch instructions are handled in the backend, where do I have to look first? I'm not familiar with the backend framework and I couldn't figure out the interface between the LLVM instruction 'SwitchInst' and whatever there is in the backend. I would be very happy about every hint where I have to look to find the entry point of switch instructions in the

PHI nodes within machine code were originally used by the Sparc back-end but they turned out not to be necessary. Instead, LLVM phis are lowered to copy instructions in the machine code (I believe this happens just after instruction selection). As far as I know, the machine PHI nodes are not used by the x86 back-end and you shouldn't need them if you insert the right copies. --Vikram

...e the machine code is in SSA, we need to use the Machine code PHI nodes to specify this to the target-independent register allocator so that it can coallesce registers appropriately, if possible. The SparcV9 backend does not implement the 'select' instruction directly, it is lowered by the LowerSelect pass before V9 instruction selector. Furthermore, V9 has a conditional move instruction which some other architectures lack, so they need the MachineCode PHI nodes to work with the target-independent register allocator. > As far as I know, the machine PHI nodes are not used by the x86 > bac...

...GetElementPtrInst *gepinst = new GetElementPtrInst(itext, ConstantInt::get(Type::Int32Ty, 0), ConstantInt::get(Type::Int32Ty, 0), "", *wp); but it fails as follows: opt -load ~/llvm-tools/mcp-build/Debug/lib/MCPTransforms.so -trace-instructions -lowerselect -lowerallocs -lowergc -lowerinvoke -lowerswitch -reg2mem -insertyieldpoints -trace-memory -o Abort.fbc Abort.bc opt: /usr/local/rse/llvm/src/lib/VMCore/Instructions.cpp:872: const llvm::Type* checkType(const llvm::Type*): Assertion `Ty && "Invalid GetElementPtrInst indices for type!&q...