similar to: [LLVMdev] Implementing select_cc without cmov

someguy wrote: > Hi All, > > I need to implement select_cc as a "cmp; mov rX,1; brcond cnd, END; > mov rX,0; END:" sequence. > > Chris mentioned that the PPC code (as well as the x86 SSE code) does > this, but I can't seem to find it. > > What I really need to kmow is how to insert the branch/label pair at > instruction selection phase. > > Anyone

Hi all, I've spent the day trying to understand setcc/select_cc intricacies, and I thought I should mention that so far as I can tell, the modeling of CPU flags, condition codes and therefore conditional instructions seems pretty broken. On the one hand there are the SDNPInFlag/SDNPOutFlag node properties which allow you to mark an instruction as using or def-ing the CPU flags

Hello, I'd like to write some unit tests which verifies SELECT_CC and BR_CC lowering for ARM target, but I'm almost completely unfamiliar with llvm/Target. How can I get this nodes in DAG? Thanks. -- Kind regards, Dmitry Borisenkov -------------- next part -------------- An HTML attachment was scrubbed... URL:

Can someone explain how the condition code is passed from the MBlazeTargetLowering::LowerSELECT_CC to MBlazeTargetLowering::EmitCustomSelect custom inserter? In LowerSELECT_CC the condition code is never accessed (Op.GetOperand(4)) and I don't see how it ends up getting correctly passed to the MBlazeTargetLowering::EmitCustomSelect. > SDValue

On Tue, Mar 15, 2016 at 2:21 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 3/15/2016 4:16 PM, Rail Shafigulin via llvm-dev wrote: > >> Below is the output of llc with a -debug-only=isel. As you could see the >> output type for load, store, and add changes from v4i32 to i32 during >> legalization. How can I preserve the output type to

I am trying to add support for select_cc. In ARM it can be implemented with: mov $dst, $falseVal cmp $a, $b moveq $dst, $trueVal My current strategy is to expand select_cc in two ARM nodes: ARM::SELECT and ARM::CMP. The two nodes would be connected by a flag edge. ARM::CMP would then expand to "cmp $a, $b". This instruction has no results. It only alters the CPSR (current program

> > > That's not it at all. These model instructions reading / writing > MVT::Flag a value. That just mean from the scheduler's point of view > the node that produces a MVT::Flag and the user have to be scheduled > together. Wow. That's just super confusing. So SDNPInFlag/SNDPOutFlag is used only for scheduling? I think you're misunderstanding ISD::SETCC.

Hi Eli, Thank you very much for your response. In fact, I had already tried the X86 approach before, i.e explicitly using the status register. This is the approach that appeals more to me. I left it parked because it also produced some problems (but I left it commented out). So I have now re-lived the code, and it works fine in most cases, but there’s a particular case that causes LLVM to stop

Would it be acceptable to change MachineInstr::getRegInfo from private to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter? Cheers, Gary Evan Cheng wrote: > Look for createVirtualRegister. These are examples in > PPCISelLowering.cpp. > > Evan > On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > > > Hi Evan, > > > > Evan Cheng wrote:

Hi Eli, Thanks again for your reply. I am unsure about implementing the getCrossCopyRegClass for my target. My target does not support or allow moves to and from the SR. The SR exists because it has implicit involvement in some instructions, but it is opaque to the assembler and to the user as a register. I mean, there are no instructions to directly move or read it, or even access it directly.

I attempt to optimize the use of the ‘CMP’ instruction on my architecture by removing the instruction instances where the Status Register already had the correct status flags. The cmp instruction in my architecture is the typical one that compares two registers, or a register with an immediate, and sets the Status Flags accordingly. I implemented my ‘cmp’ instruction in LLVM by custom lowering

PPCTargetLowering::EmitInstrWithCustomInserter has a reference to the current MachineFunction for other purposes. Can you use MachineFunction::getRegInfo instead? Dan On Jul 8, 2008, at 1:56 PM, Gary Benson wrote: > Would it be acceptable to change MachineInstr::getRegInfo from private > to public so I can use it from > PPCTargetLowering::EmitInstrWithCustomInserter? > >

On Mar 22, 2009, at 7:53 AM, someguy wrote: > Hi all, > > I've spent the day trying to understand setcc/select_cc intricacies, > and I thought I should mention that so far as I can tell, the modeling > of CPU flags, condition codes and therefore conditional instructions > seems pretty broken. > > On the one hand there are the SDNPInFlag/SDNPOutFlag node properties >

Chris Lattner wrote: > On Jun 27, 2008, at 8:27 AM, Gary Benson wrote: > > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm: > > $label), > > "cmpw $rA, $rB\n\tbne- La${label}_exit", > > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm: > > $label)]>; > > } > > > > ...and

You need to insert new basic blocks and update CFG to accomplish this. There is a hackish way to do this right now. Add a pseudo instruction to represent this operation and mark it usesCustomDAGSchedInserter. This means the intrinsic is mapped to a single (pseudo) node. But it is then expanded into instructions that can span multiple basic blocks. See

Hi Rafael, > I am trying to add support for select_cc. In ARM it can be implemented > with: > > mov $dst, $falseVal > cmp $a, $b > moveq $dst, $trueVal The more normal ARM code, as produced by assembly writers and compilers that I've seen, is cmp $a, $b moveq $dst, $trueVal movne $dst, $falseVal e.g. at the end of a function returning r0 orr r0, r0, #0x40

On Mon, Aug 21, 2006 at 05:09:10PM -0300, Rafael Espíndola wrote: > I am trying to add support for select_cc. In ARM it can be implemented > with: [snip] Speaking of new backends, there is a document that lists some architecture docs: http://llvm.org/docs/CompilerWriterInfo.html . There is a link to the GCC library as well, which is rather extensive and may be helpful in writing a new

Let's consider the following piece of C code: (incomplete and not compilable ;) ) result = initValue; for(i) { ... if(condition) result = updatedValue_i; ... } For targets with conditional moves, the result is updated using the following sequence of instructions: regTmp = regFalse; if(condition2) regTmp = regTrue; regResult = regTmp; Now, you have 2 cases: 1)

> If you find any good references to optimization manuals, etc. that > aren't mentioned there, please send them along. In http://www.arm.com/products/DevTools/ABI.html there is a collection of documents regarding the ABI for the ARM architecture. Best Regards, Rafael

G'day list, It appears I got ahead of myself in believing I'd solved my CND (caller id) problem. My callerid.c change got it working on one of the handsets I have, but not the other. (Recap: The AU CND standard has an increased delay between the end of the ring signal and the start of the CND FSK data -- it's 500ms in US GR-30-CORE, and around 700ms in AU DC.002/TS030). I've