search for: adjcallstackdown64

Hi, My understanding of a "dead" register is a def that is never used. However, when I dump the MI after reg alloc on a simple program I see the 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...

...Loc(),tii.get(X86::JMP_4)).addMBB(origBB.at(1)); newEntry->push_back(plop); return false; } And here is the resulting code (it's a simple program with some 'if'): (null) BB#4 JMP_4 <BB#0> if.end BB#3 %RDI<def> = LEA64r %RIP, 1, %noreg, <ga:@.str2>, %noreg ADJCALLSTACKDOWN64 0, %RSP<imp-def>, %EFLAGS<imp-def>, %RSP<imp-use> %AL<def> = MOV8ri 0 CALL64pcrel32 <ga:@printf>, <regmask>, %RSP<imp-use>, %AL<imp-use,kill>, %RDI<imp-use,kill>, %EAX<imp-def> ADJCALLSTACKUP64 0, 0, %RSP<imp-def>, %EFLAGS<imp-def...

...the defs and the uses. -Krzysztof On 2/5/2018 11:14 PM, Bhatu via llvm-dev wrote: > Hi, > > My understanding of a "dead" register is a def that is never used. However, > when I dump the MI after reg alloc on a simple program I see the > 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 %r...

...here that opcode is set. > I believe we need to generate that instruction if it does not exist > (along with CallFrameDestroyOpcode) in the presence of TLS, at least > on X86 where's it's implemented via a function call. For X86 CALLSEQ_START gets selected to ADJCALLSTACKDOWN or ADJCALLSTACKDOWN64 in this case. So is CALLSEQ_START expected to appear only once (at the top of the function)? The comments are rather confusing. It seems like CALLSEQ_START is supposed to appear before every call, but surely there's only one stack adjustment in the final code. How does this all work? How d...

Hello, David > For X86 CALLSEQ_START gets selected to ADJCALLSTACKDOWN or > ADJCALLSTACKDOWN64 in this case.  So is CALLSEQ_START expected > to appear only once (at the top of the function)?  The comments > are rather confusing.  It seems like CALLSEQ_START is supposed > to appear before every call, but surely there's only one stack > adjustment in the final code. Right. Ever...

I discovered recently that RegAllocFast spills all the registers before every function call. This is the root cause of one of our recursive functions that takes about 150 bytes of stack when built with gcc (same at -O0 and -O2, or 120 bytes at llc -O2) taking 960 bytes of stack when built by llc -O0. That's pretty bad for situations where you have small stacks, which is not uncommon for

...insic MI->eraseFromParent(); MBB->getParent()->dump(); return MBB_cond; } Here is the dump of the original function before my custom inserter (it's basically a main function with a printf and a return inside it): # Machine code for function main: SSA BB#0: derived from LLVM BB %entry ADJCALLSTACKDOWN64 0, %RSP<imp-def,dead>, %EFLAGS<imp-def,dead>, %RSP<imp-use> %vreg2<def> = MOV32ri64 <ga:@str>; GR32:%vreg2 %vreg3<def> = SUBREG_TO_REG 0, %vreg2<kill>, 4; GR64:%vreg3 GR32:%vreg2 %RDI<def> = COPY %vreg3; GR64:%vreg3 CALL64pcrel32 <ga:@puts>, &lt...

...ew spills. RAFast uses more aggressive hinting by peeking at future instructions. This helps reduce the number of register copies when setting up parameters for a call: %reg1028<def> = MOV32rm <fi#2>, 1, %reg0, 0, %reg0 %reg1029<def> = MOV32rm <fi#2>, 1, %reg0, 4, %reg0 ADJCALLSTACKDOWN64 0, %RSP<imp-def>, %EFLAGS<imp-def>, %RSP<imp-use> %reg1030<def> = LEA64r %RIP, 1, %reg0, <ga:@.str> %reg1031<def> = MOV8r0 %EFLAGS<imp-def,dead> %RDI<def> = MOV64rr %reg1030 %ESI<def> = MOV32rr %reg1028 %EDX<def> = MOV32rr %reg1029 %...

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

Hi, I'm having some trouble wirting an instruction in the X86 backend. I made a new intrinsic and I wrote a custom inserter for my intrinsic in the X86 backend. Everything works fine, except for one instruction that I can't find how to write. I want to add this instruction in one of my machine basic block: mov [rdi], 0 How can I achieve that with the LLVM api? I tried several

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, 201...

On Tuesday 08 December 2009 15:53, Anton Korobeynikov wrote: > Hello, David > > > For X86 CALLSEQ_START gets selected to ADJCALLSTACKDOWN or > > ADJCALLSTACKDOWN64 in this case.  So is CALLSEQ_START expected > > to appear only once (at the top of the function)?  The comments > > are rather confusing.  It seems like CALLSEQ_START is supposed > > to appear before every call, but surely there's only one stack > > adjustment in the fin...

On Tuesday 08 December 2009 14:00, David Greene wrote: > I just filed PR 5723. This is a rather serious bug for us, > causing all sorts of problems in creating dynamically-linked > C++ programs due to the C++ runtime containing lots of leaf-like > routines that use thread-local storage. > > I can imagine a number of hackish workarounds, but I think probably > the right way to

I just filed PR 5723. This is a rather serious bug for us, causing all sorts of problems in creating dynamically-linked C++ programs due to the C++ runtime containing lots of leaf-like routines that use thread-local storage. I can imagine a number of hackish workarounds, but I think probably the right way to go is to mark routines with thread-local storage accesses in them as non-leaf. I guess

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:

...= tLDRspi %SP, 0, pred:14, pred:%noreg; mem:LD4[FixedStack-1] %R1<def> = tLDRspi %SP, 0, pred:14, pred:%noreg; mem:LD4[FixedStack-1] <- restore from *(NewSP+0) !! -Krzysztof On 9/26/2013 1:24 PM, Evan Cheng wrote: > 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. &g...

...gt; BB#2: derived from LLVM BB %while.body > Predecessors according to CFG: BB#2 BB#1 > %vreg4<def> = COPY %vreg11; GR64:%vreg4,%vreg11 > %vreg3<def> = COPY %vreg10; GR64:%vreg3,%vreg10 > %vreg2<def> = COPY %vreg9; GR64:%vreg2,%vreg9 > ADJCALLSTACKDOWN64 0, %RSP<imp-def>, %EFLAGS<imp-def,dead>, %RSP<imp-use> > %RDI<def> = COPY %vreg2; GR64:%vreg2 > CALL64pcrel32 <ga:@puts>, <regmask>, %RSP<imp-use>, %RDI<imp-use>, %RSP<imp-def>, ... > ADJCALLSTACKUP64 0, 0, %RSP<...

...mem:LD4[FixedStack-1] > %R1<def> = tLDRspi %SP, 0, pred:14, pred:%noreg; mem:LD4[FixedStack-1] <- restore from *(NewSP+0) !! > > > -Krzysztof > > > > On 9/26/2013 1:24 PM, Evan Cheng wrote: >> 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 replaceFrameInd...

...V64ri <ga:@.str>; GR64:%vreg5 MOV32mi <fi#0>, 1, %noreg, 0, %noreg, 0; mem:ST4[%retval] MOV32mr <fi#1>, 1, %noreg, 0, %noreg, %vreg1; mem:ST4[%argc.addr] GR32:%vreg1 MOV64mr <fi#2>, 1, %noreg, 0, %noreg, %vreg3; mem:ST8[%argv.addr] GR64:%vreg3 ADJCALLSTACKDOWN64 0, %RSP<imp-def>, %EFLAGS<imp-def>, %RSP<imp-use> %RDI<def> = COPY %vreg5; GR64:%vreg5 %AL<def> = MOV8ri 0 CALL64pcrel32 <ga:@printf>, <regmask>, %RSP<imp-use>, %AL<imp-use>, %RDI<imp-use>, %EAX<imp-def>...

...R1<def> = tLDRspi %SP, 0, pred:14, pred:%noreg; >> mem:LD4[FixedStack-1] <- restore from *(NewSP+0) !! >> >> >> -Krzysztof >> >> >> >> On 9/26/2013 1:24 PM, Evan Cheng wrote: >>> 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...