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

Akira Hatanaka via llvm-commits llvm-commits at lists.llvm.org
Fri Sep 11 15:44:27 PDT 2015


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.
>
>
Can they use -mstack-alignment=32, which is an x86 option that changes
TargetFrameLowering::StackAlignment? This currently gets passed to the
backend via TargetOptions, but it should be possible to convert it to a
function attribute.


>  -Hal
>
> >
> >
> > On Fri, Sep 11, 2015 at 2:31 PM, Akira Hatanaka < ahatanak at gmail.com
> > > wrote:
> >
> >
> >
> > I was thinking "no-stack-realign" should be a cl::opt debug option,
> > not a function attribute.
> >
> >
> >
> > Is there a use case that requires the end-user to disallow stack
> > realignment even when it's necessary to do so to be functionally
> > correct (for example, there is a local variable with a large
> > alignment)?
> >
> >
> >
> >
> >
> > On Fri, Sep 11, 2015 at 12:57 PM, Reid Kleckner via llvm-commits <
> > llvm-commits at lists.llvm.org > wrote:
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Sep 11, 2015 at 12:40 PM, Joerg Sonnenberger via llvm-commits
> > < llvm-commits at lists.llvm.org > wrote:
> >
> >
> > On Fri, Sep 11, 2015 at 06:54:39PM -0000, Akira Hatanaka via
> > llvm-commits wrote:
> > > URL: http://llvm.org/viewvc/llvm-project?rev=247450&view=rev
> > > Log:
> > > Use function attribute "stackrealign" to decide whether stack
> > > realignment should be forced.
> >
> > Can you please actually call it force_stackrealign or
> > always_realign_stack to avoid confusion?
> >
> >
> >
> > The X86 backend looks for a "no-stack-realign" attribute. Perhaps we
> > should have a string attribute "stackrealign" with three values,
> > "always", "auto", and "never". The default behavior is "auto".
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> >
> >
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150911/75fb5095/attachment.html>


More information about the llvm-commits mailing list