search for: lowerccccallto

...ORMAL_ARGUMENTS. I moved LowerFORMAL_ARGUMENTS to the location where LowerCCCArguments was in order to facilitate review (otherwise the diff would contain no useful deltas), but it should go back where it belongs afterwards. LowerX86_64CCCCallTo and LowerX86_64CCCCallTo were consolidated with LowerCCCCallTo. I haven't yet tackled merging LowerCCCCallTo and LowerTailCallTo. There net savings is 405 LOC. I'd appreciate tests on Windows and x86-64 hosts, since some of the logic was rather convoluted. — Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: &l...

...rFORMAL_ARGUMENTS to the location where > LowerCCCArguments was in order to facilitate review (otherwise the > diff would contain no useful deltas), but it should go back where it > belongs afterwards. > • LowerX86_64CCCCallTo and LowerX86_64CCCCallTo were consolidated > with LowerCCCCallTo. > • I haven't yet tackled merging LowerCCCCallTo and LowerTailCallTo. > > There net savings is 405 LOC. > > I'd appreciate tests on Windows and x86-64 hosts, since some of the > logic was rather convoluted. This rebases this patch to r45536 (http://lists.cs.uiuc.edu/pi...

...ter. > > Is the XCoreBranchLink enough of a match hint that an address wrapper > isn't required to clarify the pattern match for these call instructions? There's no wrapper in these patterns because the lowering code which creates the XCoreBranchLink SDNode (XCoreTargetLowering::LowerCCCCallTo()) doesn't add a wrapper around the callee. There is no need to add a wrapper because in the case of a call there is no ambiguity - a call of a global always use pc relative addressing on the XCore. The important thing here is that the pattern must match the nodes the introduced during the...

...ew 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==CallingConv::Fast) && "CallingConv::Fast...

On 25/07/12 18:21, Richard Osborne wrote: > On 25 Jul 2012, at 04:49, Paul Shortis wrote: > > >> Hello, >> >> I'm considering creating an LLVM backend for a 16 bit processor and >> modelling it around the (experimental) MSP430 back end. >> >> When reviewing MSP430InstrInfo.td I see >> >> def MSP430Wrapper :

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

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

...quot;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) > NumBytesForCalleeToPush = isSRet ? 4 : 0; > else > NumBytesForCalleeToPush = NumBytes; > assert(!(isVarArg && CC==CallingConv::Fast) && &g...

...tValue(); > bool isTailCall = cast<ConstantSDNode>(Op.getOperand(3))->getValue > () != 0; > > case CallingConv::Fast: > if (isTailCall && PerformTailCallOpt) > return LowerX86_TailCallTo(Op, DAG, CallingConv); > else > return LowerCCCCallTo(Op,DAG, CallingConv); > Some stylistic nitpicks. Please write the comments as: > /// IsNextInstructionReturn - Check whether.. Will do. > + assert(BI != BB->end() && "Woohooa"); > Better assertion messages please. :-) > > Why not write it like this: > ok...

...gt; 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) >> NumBytesForCalleeToPush = isSRet ? 4 : 0; >> else >> NumBytesForCalleeToPush = NumBytes; >> assert(!(isVarArg && CC==Call...

...get hook. This way > TargetLowering::LowerCallTo() can determine whether a call is > eligible for tail call elimination and insert the current ISD::CALL > node. Okay > X86TargetLowering::LowerX86_32FastCCCallTo() will not have to > handle non-tail calls. > I will then add code to LowerCCCCallTo() to check whether to use the normal calling convention CC_X86_32_C (3 registers free for argument passing) or the tail call (fastcc) calling convention CC_X86_32_TailCall (2 register free). Expect to see a new patch after i have done the testing with the whole test suite. regards arnold

...isTailCall = cast<ConstantSDNode>(Op.getOperand(3))->getValue >> () != 0; >> >> case CallingConv::Fast: >> if (isTailCall && PerformTailCallOpt) >> return LowerX86_TailCallTo(Op, DAG, CallingConv); >> else >> return LowerCCCCallTo(Op,DAG, CallingConv); > > >> Some stylistic nitpicks. Please write the comments as: >> /// IsNextInstructionReturn - Check whether.. > Will do. >> + assert(BI != BB->end() && "Woohooa"); >> Better assertion messages please. :-) >> >&gt...

Hi Arnold, This is a very good first step! Thanks! Comments below. Evan Index: test/CodeGen/X86/constant-pool-remat-0.ll =================================================================== --- test/CodeGen/X86/constant-pool-remat-0.ll (revision 42247) +++ test/CodeGen/X86/constant-pool-remat-0.ll (working copy) @@ -1,8 +1,10 @@ ; RUN: llvm-as < %s | llc -march=x86-64 | grep LCPI | count 3 ;

The patch is against revision 42247. -------------- next part -------------- A non-text attachment was scrubbed... Name: tailcall-src.patch Type: application/octet-stream Size: 62639 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070923/4770302f/attachment.obj>

Hi Arnold, Thanks for the patch. Some questions and commons: 1. Have you test it against the llvm test suite? Does it work if fp elimination optimization is turned off? 2. Please follow llvm coding convention and make sure every line fits in 80 columns. 3. enum NameDecorationStyle { None, StdCall, - FastCall + FastCall, + FastCC // the normal fastcc calling convention }; Why is

Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in