search for: adjcallstackup

...royOpcode) { ......... 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 "FrameSetup" instructions? - Volodya

Hi all, I'm very instresting in LLVM, and trying to port a dsp target on LLVM now. I found that, the Greddy Register Allocator will generate a reload instrucion just between the function call and ADJCALLSTACKUP instruction. If the reload instruction is transfered to be a load instruction finally, which uses the SP register as an operand, and the target uses the ADJCALLSTACKUP instruction to adjust the SP register's value, will the reload instruction get a bad SP register value? Let me use MBlaze to e...

...gt; 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 > "FrameSetup" instructions? Every target (not just x86...

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

Hi Martin, Pseudo CALLSEQ_START was changed in r302527, commit message contains details on the changes. However CALLSEQ_END was not modified. If your made changes to ADJCALLSTACKUP to add additional argument, that may result in error. Thanks, --Serge 2017-09-15 19:09 GMT+07:00 Martin 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 se...

...eg1030 = 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_2> ADJCALLSTACKUP 56 ADJCALLSTACKDOWN 56 %r3 = OR4 %reg1034, %reg1034 %r4 = OR4 %reg1033, %reg1033 BL <ga:printf>, %r3, %r4 %reg1035 = OR4 %r3, %r3 ADJCALLSTACKUP 56 %r3 = OR4 %reg1030, %reg1030 BLR ------------------------------------------------...

...let hasCtrlDep = 1, hasSideEffects = 1, isCodeGenOnly = 1, Defs = [SP], Uses = [SP] in { def ADJCALLSTACKDOWN : Pseudo<(outs), (ins i32imm:$amt1, i32imm:$amt2), [(MyCallseqStart timm:$amt1, timm:$amt2)]>; def ADJCALLSTACKUP : Pseudo<(outs), (ins i32imm:$amt1, i32imm:$amt2), [(MyCallseqEnd timm:$amt1, timm:$amt2)]>; } def Custom_CALL : Pseudo<(outs), (ins IRF32:$target, variable_ops),...

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

...nt(NumBytesForCalleeToPush, getPointerTy ())); Ops.push_back(InFlag); Chain = DAG.getNode(ISD::CALLSEQ_END, NodeTys, &Ops[0], Ops.size()); InFlag = Chain.getValue(1); The third operand is the number of bytes the callee pops of the stack on return (on x86). This gets lowered to a ADJCALLSTACKUP pseudo machineinstruction. Later when X86RegisterInfo::eliminateCallFramePseudoInstr is called and framepointerelimination is enabled the following code gets called: ... else if (I->getOpcode() == X86::ADJCALLSTACKUP) { // If we are performing frame pointer elimination and if the...

...cording 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 ADJCALLSTACKDOWN 96, %R1<imp-def,dead>, %R1<imp-use> 31 > %X3<def> = COPY %vreg16; G8RC:%vreg16 > 32 BL8_NOP <ga:@callNonVoid>, <regmask **LONG LIST**>, > %X3<imp-use>, %X2<i...

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 custom handling of stack adj...

...eg, %3:tgpr, <regmask $lr $d8 $d9 $d10 $d11 $d12 $d13 $d14 $d15 $q4 $q5 $q6 $q7 $r4 $r5 $r6 $r7 $r8 $r9 $r10 $r11 $s16 $s17 $s18 $s19 $s20 $s21 $s22 $s23 $s24 $s25 $s26 $s27 and 35 more...>, implicit-def dead $lr, implicit $sp, implicit $r0, implicit $r1, implicit $r2, implicit-def $sp 160B ADJCALLSTACKUP 0, 0, 14, $noreg, implicit-def dead $sp, implicit $sp 176B ADJCALLSTACKDOWN 0, 0, 14, $noreg, implicit-def dead $sp, implicit $sp 192B $r0 = COPY %0:tgpr 208B $r1 = COPY %1:tgpr 224B $r2 = COPY %2:tgpr 240B tBLXr 14, $noreg, %3:tgpr, <regmask $lr $d8 $d9 $d10 $d11 $d12 $d13 $d14 $d15 $...

On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote: > If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find. > Tried it, and it seems to break quite a big chunk of our tests on SPU :) Before r103488 ("Mostly rewrite RegAllocFast") there was no problem. But with r103488, I get a:

...eg, %3:tgpr, <regmask $lr $d8 $d9 $d10 $d11 $d12 $d13 $d14 $d15 $q4 $q5 $q6 $q7 $r4 $r5 $r6 $r7 $r8 $r9 $r10 $r11 $s16 $s17 $s18 $s19 $s20 $s21 $s22 $s23 $s24 $s25 $s26 $s27 and 35 more...>, implicit-def dead $lr, implicit $sp, implicit $r0, implicit $r1, implicit $r2, implicit-def $sp 160B ADJCALLSTACKUP 0, 0, 14, $noreg, implicit-def dead $sp, implicit $sp 176B ADJCALLSTACKDOWN 0, 0, 14, $noreg, implicit-def dead $sp, implicit $sp 192B $r0 = COPY %0:tgpr 208B $r1 = COPY %2:tgpr 224B $r2 = COPY %1:tgpr 240B tBLXr 14, $noreg, %3:tgpr, <regmask $lr $d8 $d9 $d10 $d11 $d12 $d13 $d14 $d15 $...

I just changed the default register allocator for -O0 builds to the fast allocator. This means that the local register allocator is not used anymore, and since it does more or less the same as the fast allocator, there is no reason to keep it around. I am going to delete it in a week or two. If you are using the local register allocator, please try switching to the fast allocator and report any

...Y %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>, %D6<imp-use,kill>, %SP<imp-def>, %D0<imp-def> 4560B ADJCALLSTACKUP 16, 0, %SP<imp-def>, %SP<imp-use> 4576B %vreg262<def> = COPY %D0<kill>; AFGR64:%vreg262 4592B %vreg263<def> = FMUL_D32 %vreg256, %vreg262; AFGR64:%vreg263,%vreg256,%vreg262 4608B ADJCALLSTACKDOWN 16, %SP<imp-def>, %SP<imp-use> 4624B %vreg264<def>...

...2 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 ADJCALLSTACKDOWN 96, %R1<imp-def,dead>, %R1<imp-use> 31 %X3<def> = COPY %vreg16; G8RC:%vreg16 32 BL8_NOP <ga:@callNonVoid>, <regmask **LONG LIST**>, %X3<imp-use>, %X2<imp-use>, %R1<i...

...our CALL. Didn't think you would need it." The problem is this code: BB#0: derived from LLVM BB %0 BRASL <ga:@extFunc>, %R0<imp-def>, %R1<imp-def>, %R3<imp-def>, %R0<imp-use>, ... %reg1028<def> = ILv4i32 0 %reg1027<def> = ORi64_v2i64 %reg1028 ADJCALLSTACKUP 0, %R1<imp-def>, %R1<imp-use> %reg1029<def> = LRr32 %R3 The return value from the call is in %R3, but %reg1027 and %reg1028 are also allocated to %R3 before it is copied to a safe place (%reg1029). RegAllocFast does not distinguish between call-clobbered registers and return va...

...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 %reg1031 = IMPLICIT_DEF_GR32 %EAX = MOV32rr %reg1031 RET My allocator produces this mapping: FNSTCW16m := MOV8mi := FLDCW16m := MOV32rm EAX := MOV32rm EAX := EAX MOVSX32r...

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