search for: sub32ri

...mple code: %gs holds a base address to a memory location where I am trying to store information. I am trying to update the %gs register pointer location before saving more values, etc. LLVM C++ codeMachine Function pass code: MachineInstrBuilder sss = BuildMI(MBB, MBB.begin(), DL, TII->get(X86::SUB32ri),X86::GS) .addReg(X86::GS) .addImm(0x8); machine function pass dump: %gs = SUB32ri %gs, 8, implicit-def %eflags Objdump -d assembly from executable 400510: 81 ed 04 00 00 00 sub $0x8,%ebp TLDR: I am trying to create custom assembly via Build...

...generate and assemble it with llvm-mc. This will tell you if its even valid. After that you can use -show-inst to print the names of the instructions that X86 uses that you can give to BuildMI. ~Craig On Sat, Jun 23, 2018 at 5:36 PM Craig Topper <craig.topper at gmail.com> wrote: > The SUB32ri can't instruction can't operate on segment registers. It > operates on EAX/EBX/EDX/ECX/EBP, etc. When it gets encoded only 3 or 4 bits > of the register value make it into the binary encoding. Objdump just > extracts those 3 or 4 bits back out and prints one of the > EAX/EBX/EDX...

...nown use of instruction mnemonic without a size suffix" > > Just curious, what does it mean by size suffix?? > > It's super cool to see the equivalent with "-show-inst"!!! Thank you > so much for this help! > > Last note, I know that the definitions (e.g. def SUB32ri) of the > various instructions can be found in the various ****.td, but is there > documentation where the meaning or quick reference of every > X86::XXXXXX llvm instruction macro can found, so I can quickly pick > and choose which actual macro I need to use, to "work forwards&quot...

...t; >> > >> Just curious, what does it mean by size suffix?? > >> > >> It's super cool to see the equivalent with "-show-inst"!!! Thank you > >> so much for this help! > >> > >> Last note, I know that the definitions (e.g. def SUB32ri) of the > >> various instructions can be found in the various ****.td, but is there > >> documentation where the meaning or quick reference of every > >> X86::XXXXXX llvm instruction macro can found, so I can quickly pick > >> and choose which actual macro I need...

...ea + X86MachineFunctionInfo *X86FI = MF.getInfo<X86MachineFunctionInfo>(); + int32_t TailCallReturnAddrDelta = X86FI->getTCReturnAddrDelta(); Why using int32_t instead of int in some of the places? Nothing "wrong" with it, just inconsistent. + // If there is an SUB32ri of ESP immediately before this instruction, + // merge the two. This can be the case when tail call elimination is + // enabled and the callee has more arguments then the caller + if (MBBI != MBB.begin()) { + MachineBasicBlock::iterator PI = prior(MBBI); + unsigned...

...ET # End machine code for function main. before replace frame indices # Machine code for function main: Post SSA Frame Objects: fi#0: size=1024, align=4, at location [SP-1024] fi#1: size=1024, align=4, at location [SP-2048] BB#0: derived from LLVM BB %entry %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead>; flags: FrameSetup PROLOG_LABEL <MCSym=.Ltmp0> CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> %ESP<def,tied1> = ADD32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,de...

On Tue, Mar 17, 2015 at 6:14 PM, Tim Northover <t.p.northover at gmail.com> wrote: >> As a simplification, the compiler deals almost exclusively in pseudo >> instructions. By x86 analogy, using pseudos to unfold a TEST32rm into >> MOV32rm + TEST32rr means I can skip the complex operand fitting effort >> needed to pick specific machine instructions. There are many

...n. > > before replace frame indices > # Machine code for function main: Post SSA > Frame Objects: > fi#0: size=1024, align=4, at location [SP-1024] > fi#1: size=1024, align=4, at location [SP-2048] > > BB#0: derived from LLVM BB %entry > %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead>; flags: FrameSetup > PROLOG_LABEL <MCSym=.Ltmp0> > CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> > %ESP<def,tied1> = ADD32ri %ESP<tied0>, 2060, %EFLAGS<im...

...e frame indices >> # Machine code for function main: Post SSA >> Frame Objects: >> fi#0: size=1024, align=4, at location [SP-1024] >> fi#1: size=1024, align=4, at location [SP-2048] >> >> BB#0: derived from LLVM BB %entry >> %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, >> %EFLAGS<imp-def,dead>; flags: FrameSetup >> PROLOG_LABEL <MCSym=.Ltmp0> >> CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> >> %ESP<def,tied1> = ADD32ri %ESP<tied0>...

...e callee pops // something off the stack pointer, add it back. We do this until we have // more advanced stack pointer tracking ability. if (uint64_t CalleeAmt = I->getOperand(1).getImm()) { unsigned Opc = (CalleeAmt < 128) ? (Is64Bit ? X86::SUB64ri8 : X86::SUB32ri8) : (Is64Bit ? X86::SUB64ri32 : X86::SUB32ri); MachineInstr *New = BuildMI(TII.get(Opc), StackPtr).addReg(StackPtr).addImm (CalleeAmt); MBB.insert(I, New); } } I am not sure about a command line switch would toggling the stack adjusting behaviour of a fun...

...D#21): Predecessors according to CFG: 0x8c53a90 0x8c55b50 MOV32mi %EBP, 1, %NOREG, -224, <ga:DataStore> %EAX = MOV32rm %EBP, 1, %NOREG, -224 %EAX = ADD32ri8 %EAX, 40 MOV32mi %EAX, 1, %NOREG, 0, 0 MOV32mi %EAX, 1, %NOREG, 4, 1075576832 %ESP = SUB32ri %ESP, 16 %XMM0 = CVTSI2SDrr %EDI MOVSDmr %ESP, 1, %NOREG, 0, %XMM0 MOV32mr %EBP, 1, %NOREG, -268, %ESP ADD32mi8 %EBP, 1, %NOREG, -268, 4294967288 %ESP = MOV32rm %EBP, 1, %NOREG, -268 %ESI = MOV32rm %EBP, 1, %NOREG, -224 %ESI = ADD32ri8 %ESI, 1...

Hi all, I changed the code that checks whether a tail call is really eligible for optimization so that it performs the check/fix in SelectionDAGISel.cpp:BuildSelectionDAG() as suggest by Evan. Also eliminated an error that caused the remaining failing test cases in the test-suite. The results look very nice (on darwin x86, r42486). The same number (46) of failing test cases on patched

CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. That means when the code is expected to be called before the pseudo instructions are eliminated. I don't know why it's not the case for you. A quick look at PEI code indicates the pseudo's should not have been removed at the time when replaceFrameIndices are run. Evan On Sep 25, 2013, at 8:57 AM, Krzysztof

On Tue, 25 Sep 2007, Evan Cheng wrote: >> the stack adjustment only fastcc was not one of them. Now that fastcc >> can cause tail call optimization i had to change the convention from >> caller pops arguments to callee pops arguments in order to allow tail >> call optimization in a general way. > > Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately

Hi All, I'm dealing with a problem where the spill/restore instructions inserted during scavenging span an adjustment of the SP/FP register. The result is that despite the base register (SP/FP) being changed between the spill and the restore, both store and load use the same immediate offset. I see code in the PEI (replaceFrameIndices) that is supposed to track the SP/FP adjustment:

..., 1, %NOREG, -268 MOV32mr %EAX, 1, %NOREG, 0, %EDI CALLpcrel32 <ga:test3_trueBlock_trueBlock.ret.exitStub_newFuncRoot.ce_trueBlock.ret.exitStub.ret.exitStub.ret.exitStub.ret7> %EAX = MOV32rm %EBP, 1, %NOREG, -268 %ESI = MOV32rm %EAX, 1, %NOREG, 0 %ESP = SUB32ri %ESP, 8 MOV32mr %ESP, 1, %NOREG, 4, %ESI MOV32mi %ESP, 1, %NOREG, 0, <ga:str> CALLpcrel32 <ga:printf> %ESP = ADD32ri8 %ESP, 8 Successors according to CFG: 0xa60cb58 trueBlock.ret (0xa60cb58, LLVM BB @0xa5d88c8, ID#83): Predecessors according to C...

...something off the stack pointer, add it back. We do this > until we have > // more advanced stack pointer tracking ability. > if (uint64_t CalleeAmt = I->getOperand(1).getImm()) { > unsigned Opc = (CalleeAmt < 128) ? > (Is64Bit ? X86::SUB64ri8 : X86::SUB32ri8) : > (Is64Bit ? X86::SUB64ri32 : X86::SUB32ri); > MachineInstr *New = > BuildMI(TII.get(Opc), StackPtr).addReg(StackPtr).addImm > (CalleeAmt); > MBB.insert(I, New); > } > } > > I am not sure about a command line switch would toggli...

...tack pointer, add it back. We do this >> until we have >> // more advanced stack pointer tracking ability. >> if (uint64_t CalleeAmt = I->getOperand(1).getImm()) { >> unsigned Opc = (CalleeAmt < 128) ? >> (Is64Bit ? X86::SUB64ri8 : X86::SUB32ri8) : >> (Is64Bit ? X86::SUB64ri32 : X86::SUB32ri); >> MachineInstr *New = >> BuildMI(TII.get(Opc), StackPtr).addReg(StackPtr).addImm >> (CalleeAmt); >> MBB.insert(I, New); >> } >> } >> >> I am not sure abou...

...isConvertibleToThreeAddress = 1 in { // Can transform into LEA. > +def TCADD32ri : Ii32<0x81, MRM0r, (outs GR32:$dst), (ins GR32: > $src1, i32imm:$src2), > + "add{l}\t{$src2, $dst|$dst, $src2}", > + []>; > +} > + > +def TCSUB32ri : Ii32<0x81, MRM5r, (outs GR32:$dst), (ins GR32: > $src1, i32imm:$src2), > + "sub{l}\t{$src2, $dst|$dst, $src2}", > + []>; > + In an intermediate implementation (that did not work anyway) i need to differentiate between the norm...

Hi llvm-dev! I have attached the current state of my GSoC work in patches [1] for review; this currently allows LLVM to correctly handle functions running out of stack space and variable sized stack objects. Firstly, since I think it is better to get things merged in small chunks, I'd like to have some specific feedback on where my work stands in terms of mergeability. Secondly, I had been