search for: callseq_end

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

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

...plified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>, SDTCisVT<1, i32>]>, [SDNPHasChain, SDNPOutGlue]>; def MyCallseqEnd : SDNode<"ISD::CALLSEQ_END", SDCallSeqEnd<[SDTCisVT<0, i32>, SDTCisVT<1, i32>]>, [SDNPHasChain, SDNPOptInGlue, SDNPOutGlue]>; def my_call : SDNode<"MyISD::CALL", SDTypeProfile<0, -1, [SDTCisPtrTy<0>]>,...

...; line argument. I think enabling this as llcbeta for a few nights > makes > sense before turning it on by default. No not directly. The code related to "caller/callee cleans arguments off the stack" is not controlled by the .td. It's controlled in code by the operands of CALLSEQ_END. for example in SDOperand X86TargetLowering::LowerCCCCallTo: ... if (CC == CallingConv::X86_StdCall || CC == CallingConv::Fast) { if (isVarArg) NumBytesForCalleeToPush = isSRet ? 4 : 0; else NumBytesForCalleeToPush = NumBytes; assert(!(isVarArg && CC==Callin...

...lue of the call iff any. const bool HasDef = !Tmp->getType()->isVoidTy(); @@ -275,10 +278,10 @@ static SDNode *lowerCallFromStatepoint(const CallInst &CI, // We just emitted a call, so it should be last thing generated SDValue Chain = Builder.DAG.getRoot(); - - // Find closest CALLSEQ_END walking back through lowered nodes if needed SDNode *CallEnd = Chain.getNode(); int Sanity = 0; + + // Find closest CALLSEQ_END walking back through lowered nodes if needed while (CallEnd->getOpcode() != ISD::CALLSEQ_END) { CallEnd = CallEnd->getGluedNode(); assert(CallEnd...

...ant:i32<0> t47: ch,glue = CopyToReg t46, Register:i64 %reg0, t2 t48: ch,glue = CopyToReg t47, Register:i64 %reg1, t4, t47:1 t50: ch,glue = SHAVEISD::CALL t48, TargetExternalSymbol:i32'__divdi3', Register:i64 %reg0, Register:i64 %reg1, RegisterMask:Untyped, t48:1 t51: ch,glue = callseq_end t50, TargetConstant:i32<0>, TargetExternalSymbol:i32'__divdi3', t50:1 t52: i64,ch,glue = CopyFromReg t51, Register:i64 %reg0, t51:1 t11: ch = CopyToReg t0, Register:i64 %vreg0, t2 t13: ch = CopyToReg t0, Register:i64 %vreg1, t4 t15: ch = CopyToReg t0, Registe...

Hi, During isel lowering, the backend insertes CALLSEQ_START / CALLSEQ_END target independent nodes to the DAG. These are then selected to X86 specific instructions ADJCALLSTACKDOWN / ADJCALLSTACKUP. At these point, they have a constant arguments which corresponds to the fixed frame size for argument passing. But the size of the stack frame isn't finalized unt...

...e = CLPISD::COPY_TO_CALLEE_A t33, t25, FrameIndex:i16<2>, t33:1 t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26, FrameIndex:i16<3>, t35:1 t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1 t41: ch,glue = callseq_end t39, TargetConstant:i16<4>, TargetConstant:i16<0>, t39:1 t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41, FrameIndex:i16<0>, t41:1 t43: ch = CLPISD::RET_FLAG t42:1 This node is first 'combined' into node t51 (bitcast of ConstantFP f32 to Constant i32). Combining: t...

Hello, I am trying to add an instruction before each function call to add/ subtract the stack pointer by a value specified at the command line. I wonder if I can do that during lowering. For example, in X86TargetLowering::LowerCALL. I appreciate it if you give me some hints how and where I can do that. Thank you, Babak

...16<2>, > t33:1 > >   t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26, FrameIndex:i16<3>, > t35:1 > >   t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float > (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1 > > t41: ch,glue = callseq_end t39, TargetConstant:i16<4>, > TargetConstant:i16<0>, t39:1 > > t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41, FrameIndex:i16<0>, t41:1 > >   t43: ch = CLPISD::RET_FLAG t42:1 > > This node is first ‘combined’ into node t51 (bitcast of ConstantFP f32 &gt...

Hi, Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization? I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern. I'm facing many situations where some patterns are lowered into

Comments: CheckDAGForTailCallsAndFixThem - 1. for (SelectionDAG::allnodes_iterator BE = DAG.allnodes_begin(), + BI = prior(DAG.allnodes_end()); BI != BE; BI--) { Please use pre-decrement instead of post-decrement. 2. The function is slower than it should be. You are scanning all the nodes in the DAG twice. You should just examine DAG.getRoot() to make determine whether it's a

...I think enabling this as llcbeta for a few nights >> makes >> sense before turning it on by default. > No not directly. The code related to "caller/callee cleans arguments > off the stack" is not controlled by the .td. It's controlled in code > by the operands of CALLSEQ_END. Ok, that's even easier to have it be controlled by the command line option. Evan > > for example in SDOperand X86TargetLowering::LowerCCCCallTo: > ... > if (CC == CallingConv::X86_StdCall || CC == CallingConv::Fast) { > if (isVarArg) > NumBytesForCalleeToP...

...t;2>, > t33:1 > >   t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26, > FrameIndex:i16<3>, > t35:1 > >   t39: ch,glue = CLPISD::CALLSEQ t37, TargetGlobalAddress:i16<float > (float, float, float, float)* @fdivfaddfmul_a> 0, t37:1 > > t41: ch,glue = callseq_end t39, TargetConstant:i16<4>, > TargetConstant:i16<0>, t39:1 > > t42: f32,ch,glue = CLPISD::COPY_TO_CALLER_A t41, FrameIndex:i16<0>, > t41:1 > >   t43: ch = CLPISD::RET_FLAG t42:1 > > This node is first ‘combined’ into node t51 (bitcast of ConstantFP f3...

...is as llcbeta for a few nights >>> makes >>> sense before turning it on by default. >> No not directly. The code related to "caller/callee cleans arguments >> off the stack" is not controlled by the .td. It's controlled in code >> by the operands of CALLSEQ_END. > > Ok, that's even easier to have it be controlled by the command line > option. > > Evan > >> >> for example in SDOperand X86TargetLowering::LowerCCCCallTo: >> ... >> if (CC == CallingConv::X86_StdCall || CC == CallingConv::Fast) { >> i...

...rt has number 8 -Operation TargetGlobalAddress has number 9 -Operation Register has number 10 -Operation CopyToReg has number 11 -Operation RegisterMask has number 12 -Operation MipsISD::JmpLink has number 13 -Operation TargetConstant has number 14 -Operation TargetConstant has number 15 -Operation callseq_end has number 16 -Operation Register has number 17 -Operation CopyFromReg has number 18 -Operation CopyToReg has number 19 -Operation Register has number 20 -Operation MipsISD::Ret has number 21 What I'd like to know now is how I might tell which parts of MIPS each operation in the selectionDAG p...

...32>, TargetConstant:i64<0> t12: ch,glue = CopyToReg t7, Register:i64 %X3, FrameIndex:i64<1> t16: ch,glue = PPCISD::CALL_NOP t12, TargetGlobalAddress:i64<void (%class.F*)* @_Z10EmitLValuev> 0, Register:i64 %X3, Register:i64 %X2, RegisterMask:Untyped, t12:1 t17: ch,glue = callseq_end t16, TargetConstant:i64<32>, TargetConstant:i64<0>, t16:1 t20: ch = lifetime.start t17, TargetFrameIndex:i64<0> t21: i64 = Constant<96> t22: i64 = Constant<0> t24: v4i32,ch = load<LD16[%0](align=8)(dereferenceable)> t20, FrameIndex:i64<1>, undef:i64...

Hello, Arnold. > with the sentence i tried to express the question whether there is a > way to persuade the code generator to use another register to load (or > move) the function pointer to (right before the callee saved register > restore) but thinking a little further that's nonsense. Why don't define some special op for callee address and custom lower it? I really

...n exposed API to do this? Or should there be another bit added to the Legal/Custom/Expand/Promote enum to force generation of a libcall? I'm trying to avoid duplicating work already done in the SelectionDAGLegalize source (ExpandLibCall) and want to make sure that both the call and the callseq_end are properly legalzed. -scooter

...bg !17 tail call void @h(i16 %call) #2, !dbg !18 ret void, !dbg !19 } For the second call, the AArch64 ISel lowering produces a 32-bit CopyFromReg from w0. t18: ch,glue = AArch64ISD::CALL t15, TargetGlobalAddress:i64<i16 (...)* @g> 0, RegisterMask:Untyped, test.c:5:11 t19: ch,glue = callseq_end t18, TargetConstant:i64<0>, TargetConstant:i64<0>, t18:1, test.c:5:11 t20: i32,ch,glue = CopyFromReg t19, Register:i32 $w0, t19:1, test.c:5:11 Then, TargetLowering::LowerCallTo adds a truncate node since the function return type is i16. t21: i16 = truncate t20, test.c:5:11 When low...