search for: brtarget

...t's the case. This isn't just the results of instructions, but also immediate 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...

...retargetable code generator, and I'm confused about how the SelectionDAG works. Let me give you an example from the SPARC backend (as this is what is often mentioned in the documentation). This is how the "branch always" instruction is defined: def BA : BranchSP<0b1000, (ins brtarget:$dst), "ba $dst", [(br bb:$dst)]>; The pattern that is to be matched is simply (br bb: $dst). Based on this, I would have expected the pattern for an add instruction to look somehow like this: (add IntRegs:$b, IntRegs:$c). But in reality,...

...riterEmitter::EmitPrintAliasInstruction seems to ignore instruction aliases if an operand that is not a register nor an immediate appears in the result instruction DAG. For example, the folllowing instruction alias pattern is not handled in MipsGenAsmWriter.inc because the third operand of BEQ is a brtarget: def : InstAlias<"b $offset", (BEQ ZERO, ZERO, brtarget:$offset)>; The code which decides not to include this alias is located near line 856 in AsmWriterEmitter.cpp: for (unsigned i = 0, e = LastOpNo; i != e; ++i) { ... switch (RO.Kind) { case CodeGenInstAlias::ResultOperand:...

Hi, I have added Branch condition BGEID like below… *def : Pat<(brcond (setcc (i32 GR32:$L), (i32 GR32:$R), SETGE), bb:$T),* * (BGEID (CMP GR32:$L, GR32:$R), bb:$T)>;* *def BGEID : TBT<0b101110, (outs), (ins GR32:$ra, brtarget:$offset), "bgeid\t$ra,$offset", [], IIC_BRc> {* * let rd = 0b10101;* *}* *def brtarget : Operand<OtherVT>* *{* * let PrintMethod = "printPCRelImmOperand";* * let EncoderMethod = "getBranchTargetOpValue";* * let OperandType = "OPERAND_P...

...t the results of instructions, but also immediate > 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...

...[ID=1] 0x170ec00: i16 = Constant<0> [ORD=1] [ID=8] 0x170ef00: ch = BasicBlock<bb1 0x170a5d8> [ID=10] In my InstrInfo.td file I'm trying to match BRCOND as follows: let isBranch = 1 in def CondBranch : F3_1<2, 0b000101, (outs), (ins IntRegs:$L, i16imm:$R, brtarget:$dst), "; TODO: do conditional branching.", [(brcond (seteq IntRegs:$L, simm8:$R), bb:$dst)]>; I know CondBranch only handles SETEQ, but it should still match the code above (which does "icmp eq")? Or am I wrong? Thanks! / Torgny -------------- next...

...but that operand is not even propagated in Encodeinstruction.. by the way,this is how I have defined BGEID.. *def : Pat<(brcond (setcc (i32 GR32:$L), (i32 GR32:$R), SETGE), bb:$T),* * (BGEID (CMP GR32:$L, GR32:$R), bb:$T)>;* *def BGEID : TBT<0b101110, (outs), (ins GR32:$ra, brtarget:$offset), "bgeid\t$ra,$offset", [], IIC_BRc> {* * let rd = 0b10101;* *}* I don't know where I am doing wrong.please provide your notes... Thanks, Mahesh B -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llv...

...lso immediate >> 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, >...

...augmented to specify the new op16 opcode for the new sub-target. Hence, no instructions are duplicated and this change has no effect on the custom lowering passes that can continue to hand-insert specific target instructions. def JUMP_cond : AJumpCC<0b110101, 0b110010, (outs), (ins i8imm:$cc, brtarget:$dst), "jump \t$cc, $dst", [(PBjumpcc simm8:$cc, bb:$dst)]>; Finally, I modified the build system to call "tablegen -gen-emitter" twice, first with "-emitter-instfld=Inst" to generate the encoder for KCPSM3 and then w...

...e results of instructions, but also immediate > 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:Ot...

...this by providing a lowering of the compare instruction : (CCReg only contains one register) def CMPEQ : Instr< (outs CCReg:$dst), (ins IntRegs:$lhs, IntRegs:$rhs), "cmpeq $lhs, $src", [(cmpeq IntRegs:$dst, IntRegs:$src)>; def BCC : Instr< (outs), (ins CCReg:$cc, brtarget:$addr), "bcc $addr", [(brcond CCReg:$cc, bb:$addr)] >; This worked, but for more complex programs, llvm tries to generate code to move CC and to spill CC. I was able to get rid of the 'moves' by setting the copycost to -1. For getting rid of the spills, I was forced to int...

..., (ins MEMrr:$buf), + "#EH_SJLJ_LONGJMP32", + [(SPsjlj_longjmp ADDRrr:$buf)]>, + Requires<[Is32Bit]>; + } + + let isBranch = 1, isTerminator = 1 in { + def EH_SjLj_Setup : Pseudo<(outs), (ins brtarget:$ptr), + "#EH_SjLj_Setup\t$ptr", []>, + Requires<[Is32Bit]>; + } + // Section B.1 - Load Integer Instructions, p. 90 let DecoderMethod = "DecodeLoadInt" in { defm LDSB : LoadA<"ldsb", 0b001001, 0b01100...

On Jan 20, 2012, at 6:40 AM, Jonas Paulsson wrote: > > What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do? > > Yes, I can move a CR to a GPR and save it to the stack, but due to a very irregular register file this is about 10 times more expensive than saving/restoring an ordinary register. These registers should basically never > have to

> On Jan 19, 2012, at 5:31 AM, Jonas Paulsson wrote: > LLVM would have to be extended with an RegClass/register-attribute 'spillable' > > > What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do? Yes, I can move a CR to a GPR and save it to the stack, but due to a very irregular register file this is about 10 times more expensive

...instruction def CMPri : F1<0b0000001101, (outs CondRegs:$cd), (ins GPRegs:$rn, uimm8:$uimm8), "c7 cmp\tne, $cd, $rn, $uimm8", [(set CondRegs:$cd, (setne GPRegs:$rn, uimmZExt8:$uimm8))]>; //conditional branch def BRcondrel : F3_1<0b011110, (outs), (ins CondRegs:$cd, brtarget:$offset), "$cd br\t$offset", [(brcond CondRegs:$cd, bb:$offset)]>; I want to place the setcc result in a condition reg and then do the conditional branch with the result from the condition reg. Unfortunately, this doesn't work. The Instruction Selection itself does...