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

Tom Stellard tom at stellard.net
Tue Apr 28 13:08:54 PDT 2015


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



More information about the llvm-commits mailing list