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

[Tom Stellard]

Merged to the 3.6 branch as r236067 and r236066.

-Tom

On Tue, Apr 28, 2015 at 01:23:37PM -0700, Andrew Trick wrote:
> Yes. Approved for 3.6.
> Andy
> 
> > On Apr 28, 2015, at 1:08 PM, Tom Stellard <tom at stellard.net> wrote:
> > 
> > Hi Owen, Andrew,
> > 
> > Can one of you approve this patch for the 3.6 branch.
> > 
> > Thanks,
> > Tom
> > 
> > 
> > 
> > 
> > 
> > On Fri, Mar 27, 2015 at 02:32:29PM -0700, Ahmed Bougacha wrote:
> >> 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
>