3.6.1 Nomination: r233409, r233410: tail-call and sret brokenness

[Ahmed Bougacha]

Hi Tom, all,

These fix two sides of the same coin: sret and tailcalls don't
interact well, at all.  On most in-tree targets this isn't an issue
(as they disable tailcalls at various points), but AArch64 is one
where it is, and we generate horribly broken stack-corrupting code.

This doesn't affect clang either, so is only really useful for other
frontends, targeting AArch64.

-Ahmed

------------------------------------------------------------------------
r233410 | ab | 2015-03-27 13:35:49 -0700 (Fri, 27 Mar 2015) | 10 lines

[CodeGen] Don't attempt a tail-call with a non-forwarded explicit sret.

Tailcalls are only OK with forwarded sret pointers. With explicit sret,
one approximation is to check that the pointer isn't an Instruction, as
in that case it might point into some local memory (alloca). That's not
OK with tailcalls.

Explicit sret counterpart to r233409.
Differential Revison: http://reviews.llvm.org/D8510

------------------------------------------------------------------------
r233409 | ab | 2015-03-27 13:28:30 -0700 (Fri, 27 Mar 2015) | 7 lines

[CodeGen] Don't attempt a tail-call with implicit sret.

Tailcalls are only OK with forwarded sret pointers. With sret demotion,
they're not, as we'd have a pointer into a soon-to-be-dead stack frame.

Differential Revison: http://reviews.llvm.org/D8510