search for: adjcallstackup64

...%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>, %RSP<imp-use> %ECX<def> = MOV32ri 25 MOV32mr <fi#8>, 1, %noreg, 0, %noreg, %EAX<kill>; mem:ST4[FixedStack8] %EAX<def> = COPY %ECX<kill> RET %EAX<imp-use,kill> if.else BB#2 %RDI<def> = LEA64r %RIP, 1,...

...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*, implicit %ssp, implicit-def %rsp, implicit-def %ssp ADJCALLSTACKUP64 0, 0, implicit-def dead %rsp, implicit-def dead %eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp RET 0 The ADJCALLSTACKDOWN64 has implicit-def dead %rsp. However the next instruction, CALL64pcrel32 has an implicit use of %rsp. This would be a use of %rsp as defined in ADJCALLSTACKDOW...

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

...= 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>, <regmask>, %RSP<imp-use>, %RDI<imp-use>, %RSP<imp-def>, %EAX<imp-def> ADJCALLSTACKUP64 0, 0, %RSP<imp-def,dead>, %EFLAGS<imp-def,dead>, %RSP<imp-use> %vreg4<def> = COPY %EAX; GR32:%vreg4 BURNSTACK %EFLAGS<imp-def,dead> %vreg5<def> = MOV32r0 %EFLAGS<imp-def,dead>; GR32:%vreg5 %EAX<def> = COPY %vreg5; GR32:%vreg5 RETQ %EAX # End machine c...

...sp, 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*, implicit %ssp, implicit-def > %rsp, implicit-def %ssp > ADJCALLSTACKUP64 0, 0, implicit-def dead %rsp, implicit-def dead > %eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp > RET 0 > > > The ADJCALLSTACKDOWN64 has implicit-def dead %rsp. However the next > instruction, > CALL64pcrel32 has an implicit use of %rsp. This would be a use...

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

...> 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<imp-def>, %EFLAGS<imp-def,dead>, %RSP<imp-use> > %vreg6<def> = MOV64rm %vreg3, 1, %noreg, 16, %noreg; mem:LD8[%args.0](tbaa=<badref>) GR64:%vreg6,%vreg3 > %vreg5<def> = COPY %vreg3; GR64:%vreg5,%vreg3 > %vreg5<def,tied1...

...%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> ADJCALLSTACKUP64 0, 0, %RSP<imp-def>, %EFLAGS<imp-def>, %RSP<imp-use> %vreg6<def> = COPY %EAX; GR32:%vreg6 %vreg4<def> = MOV32ri 0; GR32:%vreg4 MOV64rr %vreg7, %RSP; GR64:%vreg7 Successors according to CFG: BB#1 BB#1: derived from LLVM BB %entry Predece...

...1073741833>!(d1533,,):, d1555<RSP>!(\~d1554",d1564,u1567):, d1556<SSP>!(\~d1554",d1566,u1568):d1555, u1557<RSP>!(d1533):, u1558<SSP>!(d1535):, u1559<RDI>!(d1545):, u1560<ESI>!(d1548):, u1561<RDX>!(d1543):, u1562<R11>!(d1551):] s1563: ADJCALLSTACKUP64 [d1564<RSP>!(d1555,,u3778"):, d1565<EFLAGS>!(\~d1554",d1571,):d1556, d1566<SSP>!(d1556,,u3777"):, u1567<RSP>!(d1555):, u1568<SSP>!(d1556):] s1569: MOV32r0 [d1570<R10D>(\~d1554",,u3776"):d1565, d1571<EFLAGS>!(d1565,d1574,):...

Hi Scott, That #1073741833 is a register mask. They are treated as aggregate registers (essentially sets of registers), so if it includes R9D and R11D, it will be treated as being aliased with both. These separate defs are there because they reach disjoint registers. -- Krzysztof Parzyszek kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> AI tools development From: Scott

Hi, I'm having trouble using virtual register in the X86 backend. I implemented a new intrinsic and I use a custom inserter. The goal of the intrinsic is to set the content of the stack to zero at the end of each function. Here is my code: MachineBasicBlock * X86TargetLowering::EmitBURNSTACKWithCustomInserter( MachineInstr *MI, MachineBasicBlock

Hi all, As much as possible I would rather we avoid any kind of metadata in MIR to express the semantic of instructions. Instead I would prefer that each back provides a way to interpret what an instruction is doing. What I have in mind is something that would generalize what we do in the peephole optimizer for instance (look for isRegSequenceLike/getRegSequenceInputs and co.) or what we have for

...ri 15 > $rdi = COPY %8, debug-location !25 > $esi = COPY %1, debug-location !25 > $edx = COPY %9, debug-location !25 > $ecx = COPY %10, debug-location !25 > $r8d = COPY %6, debug-location !25 > $r9d = COPY %7, debug-location !25 > CALL64pcrel32 @foo > ADJCALLSTACKUP64 > > At MIR level, we are aware that we could extract calling convention from > foo but we are not still sure how would we recognize COPY instructions > that do not transfer call arguments. There are situations like loading > of AL for functions with variable number of arguments, or...