search for: tailcallreturnaddrdelta

...kely we'd like 0x80000000 to be interpreted as positive, rather than negative if it ever does occur. Also, CreateFixedObject seems to take an int64_t I'd suggest: + ISelLowering line 2459: cast FPDiff to int64_t. + ISelLowering line 3327: cast SlotSize to int64_t. + FrameLowering: declare TailCallReturnAddrDelta as int64_t and subtract SlotSize? It would also be really good if you could convert your IR into a test-case (like the others in "test/CodeGen/X86/"). We like to have a test-case for every commit if it's humanly possible. Cheers. Tim.

Dear LLVM developers, I am a developer of SML#, an ML-style functional programming language developed at Tohoku University. Currently we are intending to use LLVM as the backend of our SML# compiler in our upcoming release, and have rewritten our frontend and runtime so that they can cooperate with LLVM. LLVM works extremely fine with our SML# compiler. We are grateful to LLVM community for

Hi all, I changed the code that checks whether a tail call is really eligible for optimization so that it performs the check/fix in SelectionDAGISel.cpp:BuildSelectionDAG() as suggest by Evan. Also eliminated an error that caused the remaining failing test cases in the test-suite. The results look very nice (on darwin x86, r42486). The same number (46) of failing test cases on patched

On Tue, 25 Sep 2007, Evan Cheng wrote: >> the stack adjustment only fastcc was not one of them. Now that fastcc >> can cause tail call optimization i had to change the convention from >> caller pops arguments to callee pops arguments in order to allow tail >> call optimization in a general way. > > Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately

...ting whether the call is really eligible for tail call + // optimization + CheckDAGForTailCallsAndFixThem(DAG, TLI); + check -> Check to start a sentence. :-) + // Skip the RETADDR move area + X86MachineFunctionInfo *X86FI = MF.getInfo<X86MachineFunctionInfo>(); + int32_t TailCallReturnAddrDelta = X86FI->getTCReturnAddrDelta(); Why using int32_t instead of int in some of the places? Nothing "wrong" with it, just inconsistent. + // If there is an SUB32ri of ESP immediately before this instruction, + // merge the two. This can be the case when tail call elimi...