performance regression on sphereflake

[Gerolf Hoflehner]

Thanks Rafael, Renato and others for the history and discussions . This regression felt a bit fishy from the beginning, and I agree with the “bug rather than feature” assessment.  


Gerolf

On Feb 18, 2014, at 4:38 PM, Sean Silva <silvas at purdue.edu> wrote:

> 
> 
> 
> 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@163422 91177308-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
> 
> _______________________________________________
> 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/20140219/6428ba9f/attachment.html>