search for: adjcallstackdown32

...lex. I think I'd rather do folding of the simple (but common) cases on the fly. 2) Alter the semantics of ADJCALLSTACKDOWN/ADJCALLSTACKUP slightly. Doing the mov->push transformation before PEI means I'd have to leave the ADJCALLSTACKDOWN/UP pair unbalanced. E.g. something like: ADJCALLSTACKDOWN32 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> %vreg9<def,dead> = COPY %ESP; GR32:%vreg9 PUSH32rmm %vreg0, 1, %noreg, 28, %noreg, %ESP<imp-def>, %ESP<imp-use>; GR32:%vreg0 PUSH32rmm %vreg0, 1, %noreg, 24, %noreg, %ESP<imp-def>, %ESP<imp-use&gt...

...lex. I think I'd rather do folding of the simple (but common) cases on the fly. 2) Alter the semantics of ADJCALLSTACKDOWN/ADJCALLSTACKUP slightly. Doing the mov->push transformation before PEI means I'd have to leave the ADJCALLSTACKDOWN/UP pair unbalanced. E.g. something like: ADJCALLSTACKDOWN32 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> %vreg9<def,dead> = COPY %ESP; GR32:%vreg9 PUSH32rmm %vreg0, 1, %noreg, 28, %noreg, %ESP<imp-def>, %ESP<imp-use>; GR32:%vreg0 PUSH32rmm %vreg0, 1, %noreg, 24, %noreg, %ESP<imp-def>, %ESP<imp-use&gt...

...ompute because the stack pointer moves and wrong value is received. 2. the function call after line end could get wrong values because after line end the stack pointer is pointing to useful data. Could anyone working on x86 instruction selection give some pointers to prevent this? Thanks, -Peng ADJCALLSTACKDOWN32 8, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use> ; line 1 %vreg187<def> = COPY %ESP; GR32:%vreg187 ; line 2 MOVSDmr %vreg187, 1, %noreg, 0, %noreg, %vreg36; mem:ST8[Stack] GR32:%vr...

...ng value is received. > 2. the function call after line end could get wrong values because after line end the stack pointer is pointing to useful data. > > Could anyone working on x86 instruction selection give some pointers to prevent this? > > Thanks, > -Peng > > > ADJCALLSTACKDOWN32 8, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use> ; line 1 > %vreg187<def> = COPY %ESP; GR32:%vreg187 ; line 2 > MOVSDmr %vreg187, 1, %noreg,...

So, there exists registers which are reserved denoted by the Machine Register Info :: getReserved field. I am wondering if these registers are reserved or preserved? I have come across a case where a reserved register was used. Namely it's in "llvm\test\CodeGen\X86\2009-04-27-CoalescerAssert.ll" where the reserved register ESP (54) in block "bb98.fragment" on line 854. Is

...mi <fi#2>, 1, %reg0, 0, %reg0, 0 * * MOV32mr <fi#2>, 1, %reg0, 0, %reg0, %ECX<kill>* * %EAX<def> = MOV32rm <fi#2>, 1, %reg0, 0, %reg0* * MOV32mr %reg0, 1, %reg0, <ga:@one+4>, %reg0, %EAX<kill>* * %EAX<def> = MOV32rm <fi#2>, 1, %reg0, 0, %reg0* * ADJCALLSTACKDOWN32 8, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use>* * %ECX<def> = MOV32rr %ESP* * MOV32mr %ECX, 1, %reg0, 4, %reg0, %EAX<kill>; mem:ST4[Stack+4]* * MOV32mi %ECX<kill>, 1, %reg0, 0, %reg0, <ga:@.str>; mem:ST4[Stack]* * CALLpcrel32 <ga:@printf>...

....ll -print-before-all # *** IR Dump Before Prologue/Epilogue Insertion & Frame Finalization ***: # Machine code for function main: Post SSA Frame Objects: fi#0: size=1024, align=4, at location [SP+4] fi#1: size=1024, align=4, at location [SP+4] BB#0: derived from LLVM BB %entry ADJCALLSTACKDOWN32 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> ADJCALLSTACKUP32 0, 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> RET # End machin...

...IR Dump Before Prologue/Epilogue Insertion & Frame Finalization ***: > # Machine code for function main: Post SSA > Frame Objects: > fi#0: size=1024, align=4, at location [SP+4] > fi#1: size=1024, align=4, at location [SP+4] > > BB#0: derived from LLVM BB %entry > ADJCALLSTACKDOWN32 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> > CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> > ADJCALLSTACKUP32 0, 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> > RET >...

...logue Insertion & Frame Finalization ***: >> # Machine code for function main: Post SSA >> Frame Objects: >> fi#0: size=1024, align=4, at location [SP+4] >> fi#1: size=1024, align=4, at location [SP+4] >> >> BB#0: derived from LLVM BB %entry >> ADJCALLSTACKDOWN32 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, >> %ESP<imp-use> >> CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> >> ADJCALLSTACKUP32 0, 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, >> %ESP<imp-use&...

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: