performance regression on sphereflake

[Sean Silva]

On Tue, Feb 18, 2014 at 7:31 PM, Bob Wilson <bob.wilson at apple.com> wrote:

> The APCS stack alignment is only 32 bits. At the time I made that change,
> we were not able to dynamically realign stack frames for ARM, so it didn't
> make sense to have a preferred aggregate alignment larger than 32 bits.
> Even now, given the cost of dynamic realignment, I don't think changing
> that would be a good idea.
>
> Besides, as I mentioned in the commit message, this change really came
> from Sandeep Patel, so I blame him for any problems with it ;-)
>

For those out of the loop, check r163422:

sean:~/pg/llvm/llvm % git log -p --grep='unfortunate' CREDITS.TXT


commit d2f43b017c4baccd40cb32e27f18d938ef2a47fe
Author: Sandeep Patel <deeppatel1987 at gmail.com>
Date:   Fri Sep 7 21:20:20 2012 +0000

    Correct an unfortunately necessary typo.

    git-svn-id:
https://llvm.org/svn/llvm-project/llvm/trunk@16342291177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/CREDITS.TXT b/CREDITS.TXT
index f090ad7..7a1bacd 100644
--- a/CREDITS.TXT
+++ b/CREDITS.TXT
@@ -328,10 +328,6 @@ D: LTO tool, PassManager rewrite, Loop Pass Manager,
Loop Rotate
 D: GCC PCH Integration (llvm-gcc), llvm-gcc improvements
 D: Optimizer improvements, Loop Index Split

-N: Sandeep Patel
-E: deeppatel1987 at gmail.com
-D: ARM calling conventions rewrite, hard float support
-
 N: Wesley Peck
 E: peckw at wesleypeck.com
 W: http://wesleypeck.com/
@@ -354,6 +350,10 @@ N: Xerxes Ranby
 E: xerxes at zafena.se
 D: Cmake dependency chain and various bug fixes

+N: Alex Rosenberg
+E: alexr at leftfield.org
+D: ARM calling conventions rewrite, hard float support
+
 N: Chad Rosier
 E: mcrosier at apple.com
 D: ARM fast-isel improvements


-- Sean Silva


>
> On Feb 18, 2014, at 4:15 PM, Rafael Espíndola <rafael.espindola at gmail.com>
> wrote:
>
> > On 18 February 2014 18:20, Renato Golin <renato.golin at linaro.org> wrote:
> >> Gerolf,
> >>
> >> AFAIK, the old APCS never tried to define the alignment of complex
> >> aggregates, or the stack.
> >>
> >> What Rafael said is true, it's more of preference (or rather,
> >> compatibility), than ABI conformance. But if it's generating
> >> regressions, we should look into.
> >>
> >> Being pragmatic, one has to look why that was set in Clang in the
> >> first place. Making it the same on both places makes sense (and why
> >> it's a good idea to have target descriptions external to both LLVM and
> >> Clang, as proposed by Jim), but we need to make sure whoever added it
> >> to Clang did it for a reason, and what reason was that.
> >
> > Good point. I did a git blame and found that the clang datalayout was
> > changed in r128825 by Bob Wilson, but it looks like he was just
> > syncing from llvm-gcc.
> >
> > There might have been a mistake in r128825. llvm-gcc would always just
> > ask llvm for a datalayout and the ARM Target back then never specified
> > an 'a' alignment for ARM:
> >
> >    DataLayout(Subtarget.isAPCS_ABI() ?
> >               std::string("e-p:32:32-f64:32:64-i64:32:64-"
> >                           "v128:32:128-v64:32:64-n32") :
> >               std::string("e-p:32:32-f64:64:64-i64:64:64-"
> >                           "v128:64:128-v64:64:64-n32")),
> >
> > Cheers,
> > Rafael
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140218/d09b7160/attachment.html>