search for: add32ri

...described above, we can specify a program location before the corresponding machine location containing the variable value machine location becomes available. Consider this code: DBG_VALUE output-of-this-inst --- someinst1 | someinst2 | $rax = ADD32ri $rax, 0 <----- Where the line from DBG_VALUE to ADD32ri represents some as-yet-undetermined way of identifying the ADD32ri instruction from the DBG_VALUE. We can interpret such a code sequence as the variable having no location across someinst1 and someinst2, which are not dominated by the...

...def : Pat<(add DLDREGS:$src1, imm:$src2), (SUBIWRdK DLDREGS:$src1, (imm16_neg_XFORM imm:$src2))>; Now, the typical pattern concerning additions with global addresses looks like this: (taken from x86) def : Pat<(add GR32:$src1, (X86Wrapper tglobaladdr :$src2)), (ADD32ri GR32:$src1, tglobaladdr:$src2)>; but i can't write that since i dont have an add with imm instr, and doing: def : Pat<(add DREGS:$src, (Wrapper tglobaladdr:$src2)), (SUBIWRdK DREGS:$src, tglobaladdr:$src2)>; is wrong because the tglobaladdr has to be negated somehow, so...

...LVM 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,dead> RET # End machine code for function main. Let's see what happens if we remove the call to "bar". There aren't any pseudocodes that set up the frame to begin with, even though the SP is actually modified. (This is...

...mm16_neg_XFORM imm:$src2))>; > Cool. That's exactly the sort of thing I was referring to. > Now, the typical pattern concerning additions with global addresses looks like this: (taken from x86) > def : Pat<(add GR32:$src1, (X86Wrapper tglobaladdr :$src2)), > (ADD32ri GR32:$src1, tglobaladdr:$src2)>; > > but i can't write that since i dont have an add with imm instr, and doing: > > def : Pat<(add DREGS:$src, (Wrapper tglobaladdr:$src2)), > (SUBIWRdK DREGS:$src, tglobaladdr:$src2)>; > is wrong because the tglobaladdr...

...> > Cool. That's exactly the sort of thing I was referring to. > > > > Now, the typical pattern concerning additions with global addresses looks > like this: (taken from x86) > > def : Pat<(add GR32:$src1, (X86Wrapper tglobaladdr :$src2)), > > (ADD32ri GR32:$src1, tglobaladdr:$src2)>; > > > > but i can't write that since i dont have an add with imm instr, and > doing: > > > > def : Pat<(add DREGS:$src, (Wrapper tglobaladdr:$src2)), > > (SUBIWRdK DREGS:$src, tglobaladdr:$src2)>; > >...

...ry > %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,dead> > RET > > # End machine code for function main. > > > > Let's see what happens if we remove the call to "bar". > > There aren't any pseudocodes that set up the frame to begin with, even tho...

...t;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,dead> >> RET >> >> # End machine code for function main. >> >> >> >> Let's see what happens if we remove the call to "bar". >> >> There aren't any pseudocodes that set up th...

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

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:

Hello, On Apr 26, 2011, at 6:30 AM, Borja Ferrer wrote: > Hello, I have some questions regarding folding operations with symbols during the instruction print stage with MC. At the moment I'm working with global symbols but i guess that other symbol types should be equivalent. > > My first question is how can i negate the address of a symbol? > > Consider this piece of code:

Hello, I have some questions regarding folding operations with symbols during the instruction print stage with MC. At the moment I'm working with global symbols but i guess that other symbol types should be equivalent. My first question is how can i negate the address of a symbol? Consider this piece of code: char g_var[80]; char foo(int a) { return g_var[a]; } this gets compiles into

...P points to the safe stack at the start of each function. The pass tracks the flow of addresses derived from ESP to other registers throughout the function to determine whether any given memory operand refers to the safe stack. It assumes that only specific types of instructions (LEA32r, MOV32rr, ADD32ri8, ADD32ri) are used to compute pointers to the safe stack. It also attempts to track the flow of addresses through register spills and fills. The pass performs a single pass over each instruction in each basic block, recording information about the flow of safe stack addresses through registers a...

...wing two instructions are used to adjust the stack > pointer > +// in the case where the callee has more arguments than the caller > +// an area is created where the return addr can be safely moved to > +let 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...

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

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

...rns, etc. 5. +// the following two instructions are used to adjust the stack pointer +// in the case where the callee has more arguments than the caller +// an area is created where the return addr can be safely moved to +let 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...

...&MBB, + unsigned StackPtr) { + int32_t Offset = 0; + if (MBBI != MBB.begin()) { + MachineBasicBlock::iterator PI = prior(MBBI); + unsigned Opc = PI->getOpcode(); + if ((Opc == X86::ADD64ri32 || Opc == X86::ADD64ri8 || + Opc == X86::ADD32ri || Opc == X86::ADD32ri8) && + PI->getOperand(0).getReg() == StackPtr){ + Offset += PI->getOperand(2).getImm(); + MBB.erase(PI); + } + } + return Offset; +} + Seems like the previous chunk can be changed to use this function with some refactoring? + +static cl...

Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in