search for: bx_ret

...caller address). It > should be available as a general purpose register. OK. > The bug is elsewhere. It has to do with kill / dead markers. > %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0 > %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0 > BX_RET 14, %reg0 > LR is restored here but it's not killed before the end of the block is > reached. Hmm. I have no idea about what ARM backend does. My register allocator just assigns the registers as I explained in my original mail. Then it lets VirtRegMap.cpp do its job, i.e. it lets it rewr...

...o CFG: 0x8fdad00 (#1) 0x8fdad70 (#2) bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: Predecessors according to CFG: 0x8fdac90 (#0) %reg1027<def> = MOVi 0, 14, %reg0, %reg0 STR %reg1024<kill>, %reg1027<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) [0x8fc2d68 + 0] BX_RET 14, %reg0 UnifiedReturnBlock: 0x8fdad70, LLVM BB @0x8fc2cc0, ID#2: Predecessors according to CFG: 0x8fdac90 (#0) BX_RET 14, %reg0 # End machine code for Insert(). 2) My register allocator produces a following allocation: ********** REGISTER MAP ********** [reg1024 -> LR] [reg102...

This looks like a bar in ARMInstrInfo.td: BX_RET should be marked with Uses = [LR] since it uses LR. However, this won't work if there is a call BL before the BX_RET. BL is marked as if it implicitly define LR. So we'll end up with this (hello world example): Live Ins: %LR %R7 %SP<def> = SUBri %SP<kill>, 8, 14,...

On Jan 9, 2009, at 11:37 AMPST, Evan Cheng wrote: > This looks like a bar in ARMInstrInfo.td: > > BX_RET should be marked with Uses = [LR] since it uses LR. However, > this won't work if there is a call BL before the BX_RET. BL is marked > as if it implicitly define LR. So we'll end up with this (hello world > example): PPC has the call (BL) marked with Defs=LR and the return (BLR) m...

...= MOVi 0, 14, %reg0, %reg0 >> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) >> [0x8fc2d68 + 0] >> %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0 >> %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0 >> BX_RET 14, %reg0 > > Ok, ignore my earlier email about BX_RET. The issue is LR should be added to > livein of BB #1. Who should do it? Do you mean that ARM backend/LiveIntervalsAnalysis/LiveVariables should do it or do you mean that my regalloc should do it? > **** Post Machine Instrs **** &...

...%R0<def> = MOVi 0, 14, %reg0, %reg0 > *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) > [0x8fc2d68 + 0] > %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0 > %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0 > BX_RET 14, %reg0 Ok, ignore my earlier email about BX_RET. The issue is LR should be added to livein of BB #1. **** Post Machine Instrs **** # Machine code for Insert(): Live Ins: R0 in VR#1025 R1 in VR#1026 entry: 0x8fdac90, LLVM BB @0x8fc2c48, ID#0: Live Ins: %R0 %R1 %LR<def> = MOVr...

...39;s the link register (caller address). It should be available as a general purpose register. The bug is elsewhere. It has to do with kill / dead markers. %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0 %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0 BX_RET 14, %reg0 LR is restored here but it's not killed before the end of the block is reached. Should BX_RET use it? Evan > > > I hope that I provided enough information to explain my problem. I > also provided my initial analysis, but may be I'm wrong. > > Can someone m...

...;>> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) >>>> [0x8fc2d68 + 0] >>>> %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0 >>>> %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0 >>>> BX_RET 14, %reg0 >>> >>> Ok, ignore my earlier email about BX_RET. The issue is LR should be added >>> to >>> livein of BB #1. >> >> Who should do it? >> Do you mean that ARM backend/LiveIntervalsAnalysis/LiveVariables >> should do it or do you m...

...g0, %reg0 >>> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) >>> [0x8fc2d68 + 0] >>> %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0 >>> %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0 >>> BX_RET 14, %reg0 >> >> Ok, ignore my earlier email about BX_RET. The issue is LR should be >> added to >> livein of BB #1. > > Who should do it? > Do you mean that ARM backend/LiveIntervalsAnalysis/LiveVariables > should do it or do you mean that my regalloc should do...

...ould only read a callee saved register ?? The case I have in mind is the link register, like LR in ARM: a typical return instruction is BX LR. BX instruction only reads LR, no need to push/pop LR just because a function ends by BX LR... The ARM backend don't have this problem because it use a BX_RET instruction, which is just a BX which implicitly use LR as operand. Seems like a workaround solution... Context of this question: I am trying to learn how backends work, for doing so I started to write a backend for ARM Cortex M0, starting from the mblaze as base. I am aware that the ARM backend...

...e to see the MachineInstr dataflow before it all gets removed. For example a simple "ret i32* @glob" function (on ARM again) gives me: BB#0: derived from LLVM BB %0 %vreg0<def> = MOVi32imm <ga:@addr>; GPR:%vreg0 %R0<def> = COPY %vreg0; GPR:%vreg0 BX_RET pred:14, pred:%noreg, %R0<imp-use> The important point here is that the BX_RET has some kind of <imp-use> of the registers that will be used to return (%R0 in this case). It gets added first in XYZTargetLowering::LowerReturn, and then selected in the .td file using a variadic node. Wh...

..., %NOREG %r8 = LDR <fi#6>, %NOREG, 0, 14, %NOREG %r9 = LDR <fi#5>, %NOREG, 0, 14, %NOREG %r10 = LDR <fi#4>, %NOREG, 0, 14, %NOREG %r11 = LDR <fi#3>, %NOREG, 0, 14, %NOREG %lr = LDR <fi#2>, %NOREG, 0, 14, %NOREG %sp = ADDri %sp<kill>, 36, 14, %NOREG, %NOREG BX_RET 14, %NOREG, %r0<imp-use,kill> The problem is the def of %r0 right after the BL. %r0 is killed at the BL but is also implicitly defed and not marked dead. I believe it should be marked dead at the implicit def, similarly to %r1. Is that right? This is probably a bug I introduced but I wan...

On 8 March 2014 00:53, Owen Anderson <resistor at mac.com> wrote: > ISDOpcodes.h contains what documentation there is on the semantics of each > opcode. And TargetOpcodes.h for a few of the post-ISel ones (mostly they're in MachineInstr form, but you'll see them with -view-sched-dags, and occasionally before). Tim.

...cording to CFG: %bb.1 %r0 = LDRi12 %stack.2, 14, %noreg %r0 = ADDri %r0, 14, 14, %noreg, %noreg STRi12 %r0, %stack.2, 14, %noreg Successors according to CFG: %bb.6 %bb.6: derived from LLVM BB %6 Predecessors according to CFG: %bb.0 %bb.2 %bb.3 %bb.4 %bb.5 %r0 = LDRi12 %stack.2, 14, %noreg BX_RET 14, %noreg I hope to get the Case value from the MI, Thanks, yaoxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180409/882c5b12/attachment-0001.html>

...o CFG: %bb.1 %r0 = LDRi12 %stack.2, 14, %noreg %r0 = ADDri %r0, 14, 14, %noreg, %noreg STRi12 %r0, %stack.2, 14, %noreg Successors according to CFG: %bb.6 %bb.6: derived from LLVM BB %6 Predecessors according to CFG: %bb.0 %bb.2 %bb.3 %bb.4 %bb.5 %r0 = LDRi12 %stack.2, 14, %noreg BX_RET 14, %noreg I hope to get the Case value from the MI, Thanks, yaoxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180409/c2c56a4f/attachment-0001.html>

...***** Function: main Ifcvt: function (0) 'main' block 0 offset 0 size 8 block 0 offset 0 size 8 JITTing function 'main' JIT: Starting CodeGen of Function main JIT: Emitting BB0 at [0x4512e010] JIT: 0x4512e010: %R0<def> = MOVi 30, 14, %reg0, %reg0 0xe3a0001e JIT: 0x4512e014: BX_RET 14, %reg0, %R0<imp-use,kill> 0xe12fff1e JIT: Finished CodeGen of [0x4512e010] Function: main: 8 bytes of text, 0 relocations JIT: Binary code: JIT: 00000000: e3a0001e e12fff1e *** I appreciate any suggestions what can I do in my situation. -- Martins Mozeiko

...o CFG: %bb.1 %r0 = LDRi12 %stack.2, 14, %noreg %r0 = ADDri %r0, 14, 14, %noreg, %noreg STRi12 %r0, %stack.2, 14, %noreg Successors according to CFG: %bb.6 %bb.6: derived from LLVM BB %6 Predecessors according to CFG: %bb.0 %bb.2 %bb.3 %bb.4 %bb.5 %r0 = LDRi12 %stack.2, 14, %noreg BX_RET 14, %noreg I hope to get the Case value from the MI, Thanks, yaoxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180410/b6d4ba6a/attachment.html>

isBarrier is not defined in BX_RET and tBX_RET instructions and the Machine Instructions Verifier (-verify-machineinstrs) give errors about that. Is it normal that isBarrier is not defined on these instructions ?

...cording to CFG: %bb.1 %r0 = LDRi12 %stack.2, 14, %noreg %r0 = ADDri %r0, 14, 14, %noreg, %noreg STRi12 %r0, %stack.2, 14, %noreg Successors according to CFG: %bb.6 %bb.6: derived from LLVM BB %6 Predecessors according to CFG: %bb.0 %bb.2 %bb.3 %bb.4 %bb.5 %r0 = LDRi12 %stack.2, 14, %noreg BX_RET 14, %noreg I hope to get the Case value from the MI, Thanks, yaoxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180409/1b55b92d/attachment.html>

On 7/23/14, 1:20 PM, Tim Northover wrote: [...] > You should probably be specifying a triple directly, and making it an > AAPCS-VFP one for good measure: "armv7-linux-gnueabihf" for example, > or "thumbv7-none-eabihf". You shouldn't even need to set FloatABI for > those two. How do I do this? (I can't find any examples, and the API is decidedly unclear...)