search for: r12w

...eadMachineInstructionElimPass for all targets. Disabling this pass makes llvm-2.7 behave as expected. What we can see when dumping the test function body at the path entry & exit is : # Machine code for function test: Function Live Ins: %R15W in reg%1024, %R14W in reg%1025, %R13W in reg%1026, %R12W in reg%1027 BB#0: derived from LLVM BB %entry Live Ins: %R15W %R14W %R13W %R12W %reg1027<def> = MOV16rr %R12W %reg1026<def> = MOV16rr %R13W %reg1025<def> = MOV16rr %R14W %reg1024<def> = MOV16rr %R15W %reg1028<def> = MOV16rm...

...saving/restoring r11. Although this is not a functionnal regression, this looks to me like a performance regression, unless the calling convention has changed (i.e. the arguments can not be clobbered anymore). I have not yet understood why, but the liveIntervals analysis dump looks dubious to me (R12W,R13W,R14W and R15W should be dead/killed livein registers) : > llc -march=msp430 -debug-only=liveintervals -o test_unused_regs.s test_unused_regs.ll ********** COMPUTING LIVE INTERVALS ********** ********** Function: test BB#0: # derived from entry livein register: R15W live th...

...0xa244bd4 (#0) CMP16ir -21, %R15W, %SRW<imp-def> JCC mbb<if.end7,0xa244cb8>, 5, %SRW<imp-use> Successors according to CFG: 0xa244c6c (#2) 0xa244cb8 (#3) if.then5: 0xa244c6c, LLVM BB @0xa1e93c0, ID#2: Live Ins: %R15W %R15B Predecessors according to CFG: 0xa244c20 (#1) %R12W<def> = MOV16ri 10 %R12W<def> = SUB16rr %R12W, %R15W<kill>, %SRW<imp-def> %R15W<def> = MOV16rr %R12W<kill> RET %R15W<imp-use,kill> if.end7: 0xa244cb8, LLVM BB @0xa1f09c0, ID#3: Live Ins: %R15W %R15B Predecessors according to CFG: 0xa244c20 (#1) %R15...

...gisterInfo.td: > > def x86_subreg_8bit : PatLeaf<(i32 1)>; > def x86_subreg_16bit : PatLeaf<(i32 2)>; > def x86_subreg_32bit : PatLeaf<(i32 3)>; > > def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, > R8W, R9W, R10W, R11W, R12W, R13W, R14W, R15W], > [AL, CL, DL, BL, SPL, BPL, SIL, DIL, > R8B, R9B, R10B, R11B, R12B, R13B, R14B, R15B]>; > > I admit the way it's specified is not very elegant. We'll clean it up > some day. > > Evan > Even in that...

...he following sequence: ADJCALLSTACKDOWN64 0, 0, 0, *implicit-def dead %rsp*, implicit-def dead %eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp CALL64pcrel32 @foo, <regmask %bh %bl %bp %bpl %bx %ebp %ebx %rbp %rbx %r12 %r13 %r14 %r15 %r12b %r13b %r14b %r15b %r12d %r13d %r14d %r15d %r12w %r13w %r14w %r15w>, *implicit %rsp*, implicit %ssp, implicit-def %rsp, implicit-def %ssp ADJCALLSTACKUP64 0, 0, implicit-def dead %rsp, implicit-def dead %eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp RET 0 The ADJCALLSTACKDOWN64 has implicit-def dead %rsp. However the next inst...

...gt;> def x86_subreg_8bit : PatLeaf<(i32 1)>; >> def x86_subreg_16bit : PatLeaf<(i32 2)>; >> def x86_subreg_32bit : PatLeaf<(i32 3)>; >> >> def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, >> R8W, R9W, R10W, R11W, R12W, R13W, R14W, R15W], >> [AL, CL, DL, BL, SPL, BPL, SIL, DIL, >> R8B, R9B, R10B, R11B, R12B, R13B, R14B, R15B]>; >> >> I admit the way it's specified is not very elegant. We'll clean it up >> some day. >> >> E...

...ster, idx relationship. See X86RegisterInfo.td: def x86_subreg_8bit : PatLeaf<(i32 1)>; def x86_subreg_16bit : PatLeaf<(i32 2)>; def x86_subreg_32bit : PatLeaf<(i32 3)>; def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, R8W, R9W, R10W, R11W, R12W, R13W, R14W, R15W], [AL, CL, DL, BL, SPL, BPL, SIL, DIL, R8B, R9B, R10B, R11B, R12B, R13B, R14B, R15B]>; I admit the way it's specified is not very elegant. We'll clean it up some day. Evan On Oct 13, 2008, at 11:24 AM, sanjiv gupta wrote: &...

On Thu, 2008-10-02 at 11:19 -0700, Evan Cheng wrote: > > On Oct 2, 2008, at 11:02 AM, Sanjiv.Gupta at microchip.com wrote: > > > What’s the value produced by an INSERT_SUBREG node? Is it a chain? > > > No, insert_subreg returns a value: > > > v1 = insert_subreg v2, v3, idx > > > v1 and v2 will have the same type, e.g. i16, and v3 must have a >

...lector pass. Function Name : bitrv2 Clobbered Registers: AH AL AX BH BL BP BPL BX CH CL CX DI DIL EAX EBP EBX ECX EDI EFLAGS ESI ESP RAX RBP RBX RCX RDI RSI RSP SI SIL SP SPL R8 R9 R10 R11 R12 R13 R14 R15 R8B R9B R10B R11B R12B R13B R14B R15B R8D R9D R10D R11D R12D R13D R14D R15D R8W R9W R10W R11W R12W R13W R14W R15W How ever caller of bitrv2, makewt has callee saved registers as per CC, but this code results in segmentation fault when compliled with O1 because makewt has value of *ip in R14 register and that is stored and restore by makewt at begining of call but due to tail call optimization f...

...ADJCALLSTACKDOWN64 0, 0, 0, *implicit-def dead %rsp*, implicit-def dead > %eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp > CALL64pcrel32 @foo, <regmask %bh %bl %bp %bpl %bx %ebp %ebx %rbp %rbx > %r12 %r13 %r14 %r15 %r12b %r13b %r14b %r15b %r12d %r13d %r14d %r15d > %r12w %r13w %r14w %r15w>, *implicit %rsp*, implicit %ssp, implicit-def > %rsp, implicit-def %ssp > ADJCALLSTACKUP64 0, 0, implicit-def dead %rsp, implicit-def dead > %eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp > RET 0 > > > The ADJCALLSTACKDOWN64 has implicit...

...e location rbp - 0x8) is used in the addition to calculate the returned value. However, when I print the RegMask operand for the call machine instruction, I get the following: <regmask %BH %BL %BP %BPL %BX %EBP %EBX %RBP %RBX %R12 %R13 %R14 %R15 %R12B %R13B %R14B %R15B %R12D %R13D %R14D %R15D %R12W %R13W %R14W %R15W> I don't see xmm1 as being preserved across this call. Am I missing something? Thanks for your help! On Wed, Jun 22, 2016 at 5:01 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Rob, > > Rob Lyerly via llvm-dev wrote: > > I'm loo...

...; Clobbered Registers: > AH AL AX BH BL BP BPL BX CH CL CX DI DIL EAX EBP EBX ECX EDI EFLAGS ESI > ESP RAX > RBP RBX RCX RDI RSI RSP SI SIL SP SPL R8 R9 R10 R11 R12 R13 R14 R15 R8B > R9B R10B > R11B R12B R13B R14B R15B R8D R9D R10D R11D R12D R13D R14D R15D R8W R9W > R10W R11W > R12W R13W R14W R15W > > How ever caller of bitrv2, makewt has callee saved registers as per CC, > but this > code results in segmentation fault when compliled with O1 because makewt > has value > of *ip in R14 register and that is stored and restore by makewt at > begining of call &...

...gt; AH AL AX BH BL BP BPL BX CH CL CX DI DIL EAX EBP EBX ECX EDI EFLAGS ESI >> ESP RAX >> RBP RBX RCX RDI RSI RSP SI SIL SP SPL R8 R9 R10 R11 R12 R13 R14 R15 R8B >> R9B R10B >> R11B R12B R13B R14B R15B R8D R9D R10D R11D R12D R13D R14D R15D R8W R9W >> R10W R11W >> R12W R13W R14W R15W >> >> How ever caller of bitrv2, makewt has callee saved registers as per CC, >> but this >> code results in segmentation fault when compliled with O1 because makewt >> has value >> of *ip in R14 register and that is stored and restore by makewt at...

I am working on a project where we are integrating an existing pre-RA scheduler into LLVM and we are trying to match our peak register pressure values with the machine instruction schedulers values while using X86. I am finding some mismatches in test cases like the one attached. The registers "AH" and "AL" are live-out but not live-in and I don't see that they are defined

...me : bitrv2 > Clobbered Registers: > AH AL AX BH BL BP BPL BX CH CL CX DI DIL EAX EBP EBX ECX EDI EFLAGS ESI ESP RAX > RBP RBX RCX RDI RSI RSP SI SIL SP SPL R8 R9 R10 R11 R12 R13 R14 R15 R8B R9B R10B > R11B R12B R13B R14B R15B R8D R9D R10D R11D R12D R13D R14D R15D R8W R9W R10W R11W > R12W R13W R14W R15W > > How ever caller of bitrv2, makewt has callee saved registers as per CC, but this > code results in segmentation fault when compliled with O1 because makewt has value > of *ip in R14 register and that is stored and restore by makewt at begining of call > but due to...

...L BX CH CL CX DI DIL EAX EBP EBX ECX EDI EFLAGS ESI >>> ESP RAX >>> RBP RBX RCX RDI RSI RSP SI SIL SP SPL R8 R9 R10 R11 R12 R13 R14 R15 R8B >>> R9B R10B >>> R11B R12B R13B R14B R15B R8D R9D R10D R11D R12D R13D R14D R15D R8W R9W >>> R10W R11W >>> R12W R13W R14W R15W >>> >>> How ever caller of bitrv2, makewt has callee saved registers as per CC, >>> but this >>> code results in segmentation fault when compliled with O1 because makewt >>> has value >>> of *ip in R14 register and that is stored...

...it : PatLeaf<(i32 1)>; > >> def x86_subreg_16bit : PatLeaf<(i32 2)>; > >> def x86_subreg_32bit : PatLeaf<(i32 3)>; > >> > >> def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI, > >> R8W, R9W, R10W, R11W, R12W, R13W, R14W, R15W], > >> [AL, CL, DL, BL, SPL, BPL, SIL, DIL, > >> R8B, R9B, R10B, R11B, R12B, R13B, R14B, R15B]>; > >> > >> I admit the way it's specified is not very elegant. We'll clean it up > >> some...

...EBP EBX ECX EDI EFLAGS ESI >>>> ESP RAX >>>> RBP RBX RCX RDI RSI RSP SI SIL SP SPL R8 R9 R10 R11 R12 R13 R14 R15 R8B >>>> R9B R10B >>>> R11B R12B R13B R14B R15B R8D R9D R10D R11D R12D R13D R14D R15D R8W R9W >>>> R10W R11W >>>> R12W R13W R14W R15W >>>> >>>> How ever caller of bitrv2, makewt has callee saved registers as per CC, >>>> but this >>>> code results in segmentation fault when compliled with O1 because >>>> makewt has value >>>> of *ip in R14 regi...

...on the MSP430 backend and I have some problems implementing the calling convention. It's a 16-bit architecture which dictates that arguments should be passed in registers R15-R12. Therefore, I have something like this is a .td file: CCIfType<[i16], CCAssignToReg<[R15W, R14W, R13W, R12W]>> 32-bit arguments should be passed in R14:R15 (R12:R13). Since it's a little endian architecture, R14 (R12) should contain the least significant bytes and R15 (R13) the most significant ones. The problem is that before the calling convention is applied, i32's are legalized into...

Hi Rob, Rob Lyerly via llvm-dev wrote: > I'm looking for a way to get all the caller-saved registers (both the > register and the stack slot at which it was saved) for a given function > call site in the backend. What's the best way to grab this > information? Is it possible to get this information if I have the > MachineInstr of the function call? I'm currently