[cfe-commits] Alignment of return from __builtin_alloca

[Chandler Carruth]

On Thu, Jun 7, 2012 at 3:08 PM, David Sehr <sehr at google.com> wrote:

> Please disregard my last comment.  Implementing that will be a bit
> challenging, as stackAlign is a back end value rather than a clang
> TargetInfo value. Are there targets where stackAlign < SuitableAlign?
>

I suspect so, and that's worrisome...

I'm not intimately familiar with stack alignment and Joerg's concerns, but
it seems like a *more* aligned alloca would be fine, but a less aligned
alloca would be bad. Why is it a bad thing to increase the alignment to
SuitableAlign?


>
> David
>
> On Thu, Jun 7, 2012 at 2:57 PM, David Sehr <sehr at google.com> wrote:
> > Joerg,
> >
> > So the interesting case is where stackAlignment < SuitableAlignment.
> > Would it be reasonable with you to align to the minimum of those two?
> >
> > David
> >
> > On Thu, Jun 7, 2012 at 2:40 PM, Joerg Sonnenberger
> > <joerg at britannica.bec.de> wrote:
> >> On Thu, Jun 07, 2012 at 02:23:13PM -0700, David Sehr wrote:
> >>> I have recently been debugging a failure with one of the tests from
> >>> the gcc torture test suite and discovered that gcc and llvm seem to
> >>> differ on whether __builtin_alloca is aligned more than 0mod4 (gcc
> >>> thinks it's aligned by what clang stores inTargetInfo::SuitableAlign).
> >>
> >> It should ensure that the stack alignment invariance from the ABI is
> >> honored. I don't think it should provide a stricter alignment.
> >> Please be very careful when changing this to not violate the above.
> >>
> >> Joerg
> >> _______________________________________________
> >> cfe-commits mailing list
> >> cfe-commits at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120607/bb05cccd/attachment.html>