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

Andrew Trick atrick at apple.com
Tue Apr 28 13:23:37 PDT 2015


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




More information about the llvm-commits mailing list