[llvm] r247450 - Use function attribute "stackrealign" to decide whether stack

[Akira Hatanaka via llvm-commits]

On Fri, Sep 11, 2015 at 3:51 PM, Reid Kleckner <rnk at google.com> wrote:

> On Fri, Sep 11, 2015 at 3:30 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>> ----- Original Message -----
>> > From: "Reid Kleckner via llvm-commits" <llvm-commits at lists.llvm.org>
>> > To: "Akira Hatanaka" <ahatanak at gmail.com>
>> > Cc: "llvm-commits" <llvm-commits at lists.llvm.org>
>> > Sent: Friday, September 11, 2015 5:08:38 PM
>> > Subject: Re: [llvm] r247450 - Use function attribute "stackrealign" to
>> decide whether stack
>> >
>> >
>> >
>> > I recall some users from nvidia or Intel did something like arranging
>> > to call a function using AVX with 32-byte stack alignment, and using
>> > -mno-stackrealign to suppress the funky prologue. They would
>> > probably be better served with an ABI stack alignment override, so
>> > maybe that use case is not worth considering.
>> >
>>
>> It seems like, for this use case, we really want an attribute to specify
>> what the enhanced caller-provided stack alignment actually is, so that the
>> backend can then make the appropriate choice about generating a stack
>> realignment based on the needs of its local variables and spill slots.
>>
>
> Precisely. Actually, don't we already have an attribute for this? Isn't
> "stackrealign" equivalent to alignstack(1)?
>

I believe we can substitute "stackrealign" with alignstack=1. The only
place that needs to be changed to make them equivalent is
X86FrameLowering::calculateMaxStackAlign. We have to check whether the
function has Attribute::StackAlignment rather than "stackrealign".

That will make the backend slightly simpler. The potential downside is that
it might not be immediately clear that alignstack=1 means "force stack
realignment".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150911/d961f864/attachment.html>