performance regression on sphereflake

[Bob Wilson]

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 ;-)

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