search for: adjcallstackdown

...f (I->getOpcode() == FrameSetupOpcode || I->getOpcode() == FrameDestroyOpcode) { ......... HasCalls = true; ........ So, stack is aligned only if there is instruction with FrameSetupOpcode or FrameDestroyOpcode. In X86, it's defined as def ADJCALLSTACKDOWN : I<0, Pseudo, (ops), "#ADJCALLSTACKDOWN">; def ADJCALLSTACKUP : I<0, Pseudo, (ops), "#ADJCALLSTACKUP">; And I'm not quite sure why I need to define and insert something similar. Why can't the above code just check for call instructions, as opposed to...

...code || > I->getOpcode() == FrameDestroyOpcode) { > ......... > HasCalls = true; > ........ > > So, stack is aligned only if there is instruction with FrameSetupOpcode or > FrameDestroyOpcode. In X86, it's defined as > > def ADJCALLSTACKDOWN : I<0, Pseudo, (ops), "#ADJCALLSTACKDOWN">; > def ADJCALLSTACKUP : I<0, Pseudo, (ops), "#ADJCALLSTACKUP">; > > And I'm not quite sure why I need to define and insert something similar. Why > can't the above code just check for call instruction...

...scing (note: I've patched the IR printer to print the contents of the regmask): 4480B %vreg260<def> = LDC1 %vreg253, <cp#3>[TF=6]; mem:LD8[ConstantPool] AFGR64:%vreg260 GPR32:%vreg253 4496B %vreg261<def> = FMUL_D32 %vreg247, %vreg248; AFGR64:%vreg261,%vreg247,%vreg248 4512B ADJCALLSTACKDOWN 16, %SP<imp-def>, %SP<imp-use> 4528B %D6<def> = COPY %vreg243; AFGR64:%vreg243 4544B JAL <ga:@sin>, <regmask %FP %RA %D10 %D11 %D12 %D13 %D14 %D15 %F20 %F21 %F22 %F23 %F24 %F25 %F26 %F27 %F28 %F29 %F30 %F31 %S0 %S1 %S2 %S3 %S4 %S5 %S6 %S7 >, %RA<imp-def,dead>,...

...------------------------------------ entry (0x8605ba0, LLVM BB @0x8602d30): %reg1024 = OR4 %r3, %r3 %reg1025 = OR4 %r4, %r4 %reg1026 = LWZ 0, %reg1025 %reg1027 = LIS <ga:.str_1> %reg1028 = LIS <ga:.str_2> %reg1029 = LBZ 0, %reg1026 ADJCALLSTACKDOWN 56 %reg1030 = IMPLICIT_DEF_GPR %reg1031 = LA %reg1027, <ga:.str_1> %r3 = OR4 %reg1031, %reg1031 BL <ga:printf>, %r3 %reg1032 = OR4 %r3, %r3 <------------------- %reg1033 = EXTSB %reg1029 %reg1034 = LA %reg1028, <ga:.str_...

...s or generated files where 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 do...

Hi LLVM-Devs, I have managed to complete updating our sources from LLVM v4.0 to v5.0, but I am getting selection errors for 'callseq_end'. I am aware that the 'ADJCALLSTACKUP' and 'ADJCALLSTACKDOWN' patterns have changed, and have added an additional argument to the TD descriptions for these. There are interactions with 'ISD::CALL' and 'ISD::RET_FLAG', but so far as I can tell I have revised these in the same way as the in-tree targets have adjusted their sources. The er...

To reduce memory consumption clobbered registers are handled with RegisterMask machine operands which contain a bitset of all registers clobbered. - Matthias > On Jul 29, 2015, at 3:00 PM, Daniel Sanders <daniel.sanders at imgtec.com> wrote: > > I believe I've identified the problem with almabench but I haven't found the root cause in the compiler yet. > > The

If I'm understanding what's going on in this test correctly, what's happening is: * ARMTargetLowering::LowerCall prefers indirect calls when a function is called at least 3 times in minsize * In thumb 1 (without -fno-omit-frame-pointer) we have effectively only 3 callee-saved registers (r4-r6) * The function has three arguments, so those three plus the register we need to hold the

...ould try to teach the peephole optimizer to do it (right now it won't even try to do this folding because PUSHes store to memory), but getting it right in the general case seems complex. 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; G...

...BB#3>; CRRC:%vreg9 > 21 B <BB#2> > 22 Successors according to CFG: BB#2(0x30000000 / 0x80000000 = 37.50%) > BB#3(0x50000000 / 0x80000000 = 62.50%) > 23 > 24 BB#2: derived from LLVM BB %if.then2 > 25 Predecessors according to CFG: BB#1 > 26 ADJCALLSTACKDOWN 96, %R1<imp-def,dead>, %R1<imp-use> > 27 %vreg16<def> = COPY %vreg15; G8RC:%vreg16,%vreg15 > 28 BL8_NOP <ga:@callVoid>, <regmask **LONG LIST**>, > %X3<imp-def,dead> > 29 ADJCALLSTACKUP 96, 0, %R1<imp-def,dead>, %R1<...

For a long time we have had code for custom lowering of adjustments to the stack pointer. But until recently we did not realise that we were handling only places that provided a fixed-value for such adjustments, and the ISD nodes 'ADJCALLSTACKDOWN' and 'ADJCALLSTACKUP' are only described in our TableGen descriptions for immediates. This hasn't previous mattered as LLVM produces valid instruction sequences for variable adjustments anyway using an intermediate register. However, we have a recent requirement to also perform...

...INSTRS ********** # Machine code for function uECC_shared_secret: NoPHIs, TracksLiveness Constant Pool: cp#0: @foo, align=4 Function Live Ins: $r0 in %0, $r1 in %1, $r2 in %2 0B bb.0.entry: liveins: $r0, $r1, $r2 16B %2:tgpr = COPY $r2 32B %1:tgpr = COPY $r1 48B %0:tgpr = COPY $r0 64B ADJCALLSTACKDOWN 0, 0, 14, $noreg, implicit-def dead $sp, implicit $sp 80B %3:tgpr = tLDRpci %const.0, 14, $noreg :: (load 4 from constant-pool) 96B $r0 = COPY %0:tgpr 112B $r1 = COPY %1:tgpr 128B $r2 = COPY %2:tgpr 144B tBLXr 14, $noreg, %3:tgpr, <regmask $lr $d8 $d9 $d10 $d11 $d12 $d13 $d14 $d15 $q4...

...********* MACHINEINSTRS ********** # Machine code for function f: NoPHIs, TracksLiveness Constant Pool: cp#0: @bar, align=4 Function Live Ins: $r0 in %0, $r1 in %1, $r2 in %2 0B bb.0.entry: liveins: $r0, $r1, $r2 16B %2:tgpr = COPY $r2 32B %1:tgpr = COPY $r1 48B %0:tgpr = COPY $r0 64B ADJCALLSTACKDOWN 0, 0, 14, $noreg, implicit-def dead $sp, implicit $sp 80B %3:tgpr = tLDRpci %const.0, 14, $noreg :: (load 4 from constant-pool) 96B $r0 = COPY %0:tgpr 112B $r1 = COPY %1:tgpr 128B $r2 = COPY %2:tgpr 144B tBLXr 14, $noreg, %3:tgpr, <regmask $lr $d8 $d9 $d10 $d11 $d12 $d13 $d14 $d15 $q4...

...15 20 BCC 68, %vreg9, <BB#3>; CRRC:%vreg9 21 B <BB#2> 22 Successors according to CFG: BB#2(0x30000000 / 0x80000000 = 37.50%) BB#3(0x50000000 / 0x80000000 = 62.50%) 23 24 BB#2: derived from LLVM BB %if.then2 25 Predecessors according to CFG: BB#1 26 ADJCALLSTACKDOWN 96, %R1<imp-def,dead>, %R1<imp-use> 27 %vreg16<def> = COPY %vreg15; G8RC:%vreg16,%vreg15 28 BL8_NOP <ga:@callVoid>, <regmask **LONG LIST**>, %X3<imp-def,dead> 29 ADJCALLSTACKUP 96, 0, %R1<imp-def,dead>, %R1<imp-use> 30...

...MOV8mi <fi#0>, 1, %NOREG, 1, 2 FLDCW16m <fi#0>, 1, %NOREG, 0 %reg1024 = MOV32rm <fi#-2>, 1, %NOREG, 0 %reg1025 = MOV32rm %reg1024, 1, %NOREG, 0 %reg1026 = MOVSX32rm8 %reg1025, 1, %NOREG, 0 %reg1027 = MOVSX32rm8 %reg1025, 1, %NOREG, 1 ADJCALLSTACKDOWN 8 %reg1028 = ADD32rr %reg1026, %reg1027 %reg1029 = IMUL32rr %reg1028, %reg1027 MOV32mr %ESP, 1, %NOREG, 4, %reg1029 MOV32mi %ESP, 1, %NOREG, 0, <ga:.str_1> CALLpcrel32 <ga:printf> ADJCALLSTACKUP 8, 0 %reg1030 = MOV32rr %EAX...

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

...rtin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org>: > Hi LLVM-Devs, > > I have managed to complete updating our sources from LLVM v4.0 to v5.0, but > I am getting selection errors for 'callseq_end'. I am aware that the > 'ADJCALLSTACKUP' and 'ADJCALLSTACKDOWN' patterns have changed, and have > added an additional argument to the TD descriptions for these. > > There are interactions with 'ISD::CALL' and 'ISD::RET_FLAG', but so far as > I > can tell I have revised these in the same way as the in-tree targets have > ad...

On Thu, 29 Jun 2006, Fernando Magno Quintao Pereira wrote: > I am working in a register allocator for LLVM, and I realized that, > after I perform register allocation, there is many move instructions that > are dead code, and can safely be removed. It is easy for the RA algorithm > to remove these instructions. It seems to me that the only instructions > with dead definitions

...ould try to teach the peephole optimizer to do it (right now it won't even try to do this folding because PUSHes store to memory), but getting it right in the general case seems complex. 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; G...

On Tue, 22 Mar 2005, Vladimir Prus wrote: > The PrologEpilogInserter.cpp file aligns the stack only if > MachineFrameInfo::hasCalls returns true, which happens only if the function > has "call frame setup instruction" which my backend does not generate. > Chris suggested adding explicit MachineFrameInfo::setHasCalls call, which I've > tried, but it does not help. The