search for: adjcallstackup32

...;* * %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>, %EAX<imp-def>, %ECX<imp-def,dead>, %ESP<imp-use>, ...* * ADJCALLSTACKUP32 8, 0, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use>* * MOV32mi <fi#1>, 1, %reg0, 0, %reg0, 0* * %ECX<def> = MOV32rm <fi#1>, 1, %reg0, 0, %reg0* * MOV32mr <fi#0>, 1, %reg0, 0, %reg0, %ECX<kill>* * MOV32mr <fi#3>, 1, %reg0, 0, %reg0, %E...

...noreg, %vreg18; mem:ST4[%118+4] GR32:%vreg202,%vreg18 MOV32mr %vreg202, 1, %noreg, 0, %noreg, %vreg0; mem:ST4[%118] GR32:%vreg202,%vreg0 CALLpcrel32 <es:sin>, %EAX<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use>, ... ; line end-1 ADJCALLSTACKUP32 8, 0, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use> ; line end -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130208/37e996d9/attachment.htm...

...2:%vreg0 PUSH32rmm %vreg0, 1, %noreg, 4, %noreg, %ESP<imp-def>, %ESP<imp-use>; GR32:%vreg0 PUSH32rmm %vreg0<kill>, 1, %noreg, 0, %noreg, %ESP<imp-def>, %ESP<imp-use>; GR32:%vreg0 CALLpcrel32 <ga:@foo>, <regmask>, %ESP<imp-use>, %ESP<imp-def> ADJCALLSTACKUP32 32, 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> This, rightly, gets flagged by the verifier. My proposal is to add an additional parameter to ADJCALLSTACKDOWN to express the amount of adjustment the call sequence itself does. This is somewhat similar to the second p...

...on [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 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...

...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 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-10...

...tion [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 machine code for function main. >> >> before replace frame indices >> # Machine code for function main: Post SSA >> Frame Objects: >> fi#0:...

...2:%vreg0 PUSH32rmm %vreg0, 1, %noreg, 4, %noreg, %ESP<imp-def>, %ESP<imp-use>; GR32:%vreg0 PUSH32rmm %vreg0<kill>, 1, %noreg, 0, %noreg, %ESP<imp-def>, %ESP<imp-use>; GR32:%vreg0 CALLpcrel32 <ga:@foo>, <regmask>, %ESP<imp-use>, %ESP<imp-def> ADJCALLSTACKUP32 32, 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> This, rightly, gets flagged by the verifier. My proposal is to add an additional parameter to ADJCALLSTACKDOWN to express the amount of adjustment the call sequence itself does. This is somewhat similar to the second p...

...mem:ST4[%118+4] GR32:%vreg202,%vreg18 > MOV32mr %vreg202, 1, %noreg, 0, %noreg, %vreg0; mem:ST4[%118] GR32:%vreg202,%vreg0 > CALLpcrel32 <es:sin>, %EAX<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use>, ... ; line end-1 > ADJCALLSTACKUP32 8, 0, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use> ; line end > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.u...

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: