search for: brcond

Hi everyone, I have the following code (as part of a larger function): %0 = icmp eq i16 %a, 0 ; <i1> [#uses=1] br i1 %0, label %bb1, label %bb I would like to match this with a BRCOND, but all I get is an error message when compiling the above code that say: LLVM ERROR: Cannot yet select: 0x170f200: ch = br_cc 0x170f000, 0x170ed00, 0x170dc60, 0x170ec00, 0x170ef00 [ID=19] 0x170f000: ch = TokenFactor 0x170e560, 0x170e760, 0x170e960 [ID=18] 0x170e560: ch = CopyToReg 0x16d5748,...

...i1 t23: i1 = setcc t20, Constant:i32<0>, seteq:ch t25: i32,ch = CopyFromReg t0, Register:i32 %vreg396 t28: i1 = setcc t25, Constant:i32<255>, setugt:ch t29: i1 = and t23, t28 t37: i1 = setcc t29, Constant:i1<-1>, setne:ch t33: ch = brcond t16, t37, BasicBlock:ch<if.end65.1 0x7097330> t35: ch = br t33, BasicBlock:ch<if.then64.1 0x7097280> Here we see that the settcc has been legalized to xor, which I am fine with.. Legalizing: t37: i1 = setcc t29, Constant:i1<-1>, setne:ch Combining: t37: i1 = setcc t29, Constan...

...2<0>, seteq:ch >> t25: i32,ch = CopyFromReg t0, Register:i32 %vreg396 >> t28: i1 = setcc t25, Constant:i32<255>, setugt:ch >> t29: i1 = and t23, t28 >> t37: i1 = setcc t29, Constant:i1<-1>, setne:ch >> t33: ch = brcond t16, t37, BasicBlock:ch<if.end65.1 0x7097330> >> t35: ch = br t33, BasicBlock:ch<if.then64.1 0x7097280> >> Here we see that the settcc has been legalized to xor, which I am fine with.. >> Legalizing: t37: i1 = setcc t29, Constant:i1<-1>, setne:ch >> >...

...nd one immediate), and finally a target PC to branch to if the comparison succeeds. Great -- that all seems to mesh directly with the ISD::BR_CC opcode. However... I can't seem to use 'brcc' or 'br_cc' in the .td file.  Neither is recognized as a valid keyword.  I can use 'brcond', but given the capabilities of the CPU I'm targeting, it seems better to implement BR_CC directly and do setOperationAction(ISD::BRCOND, MVT::Other, Expand) to get BRCOND nodes expanded into BR_CC.  Correct? I tried implementing comparison operations and 'brcond' in the .td file,...

...ision is a long code sequence we have to insert that has branches within it (test for 0 divisor, etc.) Can't really emit the sequence of instructions via tblgen (can't have labels or BBs). The other alternative is a custom instruction emitter. Life could be easier if I could insert BRCONDs and other branches from within target-dependent lowering -- if I had access to the current MBB. Is this possible or just a FAQ? -scooter

...values as well. It seems to affect a smattering of node types. Any insights? For instance: where GPRegs contains types [i32, f32] def BEQ : IF8<Opc.BEQ, (ops GPRegs:$Rsrc1, GPRegs:$Rsrc2, brtarget:$SImm16), "beq $Rsrc1, $Rsrc2, $SImm16", [(brcond (i32 (seteq GPRegs:$Rsrc1, GPRegs:$Rsrc2)), bb: $SImm16)], s_br>; Tablegen reports: BEQ: (brcond:void (setcc:i32 GPRegs:i32:$Rsrc1, GPRegs:i32:$Rsrc2, SETEQ:Other), (bb:Other):$SImm16) as soon as I add a register class that supports either [v2i32] or [v4i32] I get the following: BGE:...

...> sequence we have to insert that has branches within it (test for 0 > divisor, etc.) Can't really emit the sequence of instructions via > tblgen (can't have labels or BBs). The other alternative is a custom > instruction emitter. > > Life could be easier if I could insert BRCONDs and other branches > from within target-dependent lowering -- if I had access to the > current MBB. > > Is this possible or just a FAQ? It isn't currently possible for a selection dag to represent more than one machine basic block. I think Christopher Lamb had some code that...

Hi there, I'm having a hard time with promoting operands from i1 to i32 in my backend... I have to register classes, VTs are i1 and i32. The i1 registers are only for predication and conditional jumps, so I want to use them with brcond, setcc. There are no instructions to directly load a value in an i1 register or to copy between i1 and i32, so I need the DAG Legalizing Pass to not generate any nodes with i1 operands. That's where the trouble starts. Occasionally, there are setcc's with i1 operands being legalized for any...

...lection DAG has the AND op node: t22: i8 = srl t19, Constant:i64<1> * t23: i8 = and t22, Constant:i8<1>* t24: i32 = zero_extend t23 t27: i1 = setcc t24, Constant:i32<1>, seteq:ch t29: i1 = xor t27, Constant:i1<-1> t31: ch = brcond t18, t29, BasicBlock:ch<if.else 0xa5f8d48> t33: ch = br t31, BasicBlock:ch<if.then 0xa5f8c98> The Optimized lowered selection DAG does not contain the* AND* node, but it does have a truncate which would seem to stand in for it given the result is only 1bit wide and the xor following...

...gt; > t22: i8 = srl t19, Constant:i64<1> > * t23: i8 = and t22, Constant:i8<1>* > t24: i32 = zero_extend t23 > t27: i1 = setcc t24, Constant:i32<1>, seteq:ch > t29: i1 = xor t27, Constant:i1<-1> > t31: ch = brcond t18, t29, BasicBlock:ch<if.else 0xa5f8d48> > t33: ch = br t31, BasicBlock:ch<if.then 0xa5f8c98> > > The Optimized lowered selection DAG does not contain the*AND* node, > but it does have a truncate which would seem to stand in for it given > the result is only 1bit wi...

...insert that has branches within it (test for 0 > > divisor, etc.) Can't really emit the sequence of instructions via > > tblgen (can't have labels or BBs). The other alternative is a custom > > instruction emitter. > > > > Life could be easier if I could insert BRCONDs and other branches > > from within target-dependent lowering -- if I had access to the > > current MBB. > > > > Is this possible or just a FAQ? > > It isn't currently possible for a selection dag to represent more than > one machine basic block. I think Christ...

...tering of node types. Any > insights? > > For instance: > > where GPRegs contains types [i32, f32] > > def BEQ : IF8<Opc.BEQ, > (ops GPRegs:$Rsrc1, GPRegs:$Rsrc2, brtarget:$SImm16), > "beq $Rsrc1, $Rsrc2, $SImm16", > [(brcond (i32 (seteq GPRegs:$Rsrc1, GPRegs:$Rsrc2)), bb: > $SImm16)], s_br>; > > Tablegen reports: > BEQ: (brcond:void (setcc:i32 GPRegs:i32:$Rsrc1, GPRegs:i32:$Rsrc2, > SETEQ:Other), (bb:Other):$SImm16) > > as soon as I add a register class that supports either [v2i32] or > [v...

Hi, >> DAGCombiner::visitBRCOND() has code: >> >> SDValue N1 = N->getOperand(1); >> SDValue N2 = N->getOperand(2); >> >> ... >> >> SDNode *Trunc = 0; >> if (N1.getOpcode() == ISD::TRUNCATE&& N1.hasOneUse()) { >> // Look past truncate. >>...

...the water (having everything promoted up to i32 as a consequence)? Would it be permissible to add a virtual function to TargetLowering such that the target can effectively say, "Really, the setcc is legal, no need to truncate!"? The alternative is to do fairly deep inspection of brconds to eliminate the truncate, which eventually gets expanded into: (i8:sext_in_reg (i8:truncate (i32:setcc ...))) -scooter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081212/397249df/attachment.html&...

On Jan 6, 2009, at 11:37 PM, Scott Michel wrote: > Chris: > > I was trying to avoid using the custom instruction emitter method. > Not as if I didn't look before I asked the question to see if there > was an easier way. Then no, there is no other way. -Chris

Chris: It occurred to me this morning that maybe the general solution to this particular type of problem is a custom/target-dependent DAG inserter pass, analogous to target lowering and DAG legalization. I'm not sure if this pass happens before or after legalization. Worth considering? I suppose the best way to discuss this is to just write the code. However, some preliminary

...d our intrinsic and instruction definitions accordingly, changed the data type of the predicate registers to be i8, and changed getSetCCResultType() to return i8. After doing this, the compiler builds just fine but dies at runtime trying to match some target independent operations (e.g. setcc/brcond) that appear to want an i1 for the condition code. So, my question is this: is it even possible to represent our predicate registers (and our condition codes) as i8, and if so, what hook are we missing? Thanks in advance for any help you might be able to provide. Tony -- Qualcomm Innovation...

...t; , SDT_SABREcondbr, [SDNPHasChain]>; def COND_BRANCH: Pseudo<(ops IntRegs:$a, IntRegs:$b, target:$dst), "${:comment}COND_BRANCH $a, $b, $dst", [(SABREcondbranch IntRegs:$a, IntRegs:$bm bb:$dst)]>; and I need a setOperationAction(ISD::BRCOND, MVT::Other, Expand); Im a little confused as to how BRCOND (or select for that matter) are then actually lowered to a particular branch instruction that is for the sake of argument .... BLE %a, %b, newpc ie iff %a <= %b then branch to newpc. I have been looking at the PPC and the sparc back...

...and instruction definitions accordingly, changed the data > type of the predicate registers to be i8, and changed > getSetCCResultType() to return i8.  After doing this, the compiler > builds just fine but dies at runtime trying to match some target > independent operations (e.g. setcc/brcond) that appear to want an i1 for > the condition code. > > So, my question is this: is it even possible to represent our predicate > registers (and our condition codes) as i8, and if so, what hook are we > missing? Making getSetCCResultType return i8 is definitely supported, and brcon...

...gt; > t22: i8 = srl t19, Constant:i64<1> > * t23: i8 = and t22, Constant:i8<1>* > t24: i32 = zero_extend t23 > t27: i1 = setcc t24, Constant:i32<1>, seteq:ch > t29: i1 = xor t27, Constant:i1<-1> > t31: ch = brcond t18, t29, BasicBlock:ch<if.else 0xa5f8d48> > t33: ch = br t31, BasicBlock:ch<if.then 0xa5f8c98> > > The Optimized lowered selection DAG does not contain the* AND* node, but > it does have a truncate which would seem to stand in for it given the > result is only 1bit wid...