search for: jmptarget

...inting out asm, all branch labels are printed as they should be. But when I'm trying to generate obj file, I'm getting zeros instead of PC-related offset in all branch instructions. In short, what I'm doing: - Pattern (br bb:$addr) is selected using EpiphanyInstrInfo.td as BNONE32(ins jmptarget:$addr), Branch32 class - Branch32 class is defined in EpiphanyInstrFormats.td with bits<24> addr, which should go into bits{31-8} of the MC instruction. Those bits remain zeros after relaxation for some reason. - jmptarget operand has type OPERAND_PCREL, and uses EncoderMethod "getJump...

...are printed as they should > be. But when I'm trying to generate obj file, I'm getting zeros instead of > PC-related offset in all branch instructions. > > In short, what I'm doing: > > - Pattern (br bb:$addr) is selected using EpiphanyInstrInfo.td as > BNONE32(ins jmptarget:$addr), Branch32 class > > - Branch32 class is defined in EpiphanyInstrFormats.td with bits<24> addr, > which should go into bits{31-8} of the MC instruction. Those bits remain > zeros after relaxation for some reason. > > - jmptarget operand has type OPERAND_PCREL, and uses...

...Both map to the same machine instructions through Pattern matching in TargetInstrInfo.td. This is what I mean, for the case of the Conditional Branch instruction : let Uses = [SR] in { def BRCC : T2ccbr< "br", "br"> ; } def : Pat<(CPU74brcc_g bb:$a, imm:$cc), (BRCC jmptarget:$a, imm:$cc, 0)>; def : Pat<(CPU74brcc_i bb:$a, imm:$cc, GR16:$ins), (BRCC jmptarget:$a, imm:$cc, GR16:$ins)>; Then, in MyTargetISelDAGToDAG I create ‘CPU74brcc_g' instructions if they are glued to a ‘compare’ instruction, or ‘CPU74brcc_i' instructions if they link to the resul...

Hi Lee, > let isReturn = 1, isTerminator = 1, isBarrier = 1 in > { > def RET : BitscuitInst<(outs),(ins),"JMP\tR6",[(Bitscuit_return)]>; > > def JMP : BitscuitInst<(outs), (ins jmptarget:$dst),"JMP\t$dst",[(br > bb:$dst)]>; > } Ah! It looks like the isReturn is to blame then. LLVM is presumably going through adding an implicit use of any register that will hold a return value to instructions that will actually return. This would prevent it from removing instruct...

Hi, I've been experimenting with writing a backend for LLVM (3.2) (having already written a frontend http://savourysnax.github.com/EDL), everything was going reasonably ok ( calls/returns, epilogue, prologue, etc are all working), up until I tried to place support for conditional branches. Given this simple program : int test(int c,int d) { if (c) { return

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