[PATCH] Implement X86 code generation for musttail

[Reid Kleckner]

> Would it be possible to instead change IsEligibleForTailCallOptimization to allow sib calls in cases where arguments have to be updated?

Maybe.  For musttail, we always have to be able to eliminate the tail call, regardless of what IsEligibleForTailCallOptimization says.

I started this change by making IsEligibleForTailCallOptimization return true in more cases, but ultimately I gave when I encountered MatchingStackOffset().  Evan's vision for sibcall optimization seems to be that it won't form any load and store DAG nodes.  If you go back to the old llvmdev discussion about it, he felt that -tailcallopt, or at least the DAG that it created, wasn't profitable.

IMO we could revise that to: don't do sibcall optimization if we have to move the return address, and don't generate loads and stores to move parameters if we can safely detect that we don't have to (i.e. what MatchingStackOffset does).

> For example, we should be able to consider t4 in musttail.ll to have a sibcall, no?

That would be a large, separate change for sibcall optimization, so I skipped it.

Do you think it's important to finish off this sibcall improvement before continuing with musttail, or can it wait?

================
Comment at: lib/Target/X86/X86ISelLowering.cpp:2538
@@ -2536,3 +2537,3 @@
 
-  if (MF.getTarget().Options.DisableTailCalls)
+  if (!IsMustTail && MF.getTarget().Options.DisableTailCalls)
     isTailCall = false;
----------------
Rafael Ávila de Espíndola wrote:
> This is redundant with the following if. Maybe just leaving this if as is and moving the IsMustTail definition down would be easier to read?
I agree

http://reviews.llvm.org/D3493