llvm dev - Sep 2012 - [LLVMdev] Preferred alignment of globals > 16bytes

I recently noticed that all globals bigger than 16 bytes are being 16 
byte aligned by LLVM (assuming there isn't an explicitly requested 
alignment). I'd really rather avoid this, at least for the XCore 
backend. I tracked this down to the following code in TargetData.cpp:

   if (GV->hasInitializer() && GVAlignment == 0) {
     if (Alignment < 16) {
       // If the global is not external, see if it is large.  If so, 
give it a
       // larger alignment.
       if (getTypeSizeInBits(ElemType) > 128)
         Alignment = 16;    // 16-byte alignment.
     }
   }

I was a bit surprised to see these numbers hardcoded in TargetData since 
everything else is taken from the datalayout string. I was wondering 
what the logic was behind the number 16. Would it make sense to derive 
this number from the other alignments somehow (e.g. the maximum 
preferred alignment across all types). Alternatively would it make sense 
to make it configurable in the datalayout string?

-- 
Richard Osborne | XMOS
http://www.xmos.com

On Thu, 6 Sep 2012 16:51:52 +0100
Richard Osborne <richard at xmos.com> wrote:
> I recently noticed that all globals bigger than 16 bytes are being 16 
> byte aligned by LLVM (assuming there isn't an explicitly requested 
> alignment). I'd really rather avoid this, at least for the XCore 
> backend. I tracked this down to the following code in TargetData.cpp:
> 
>    if (GV->hasInitializer() && GVAlignment == 0) {
>      if (Alignment < 16) {
>        // If the global is not external, see if it is large.  If so, 
> give it a
>        // larger alignment.
>        if (getTypeSizeInBits(ElemType) > 128)
>          Alignment = 16;    // 16-byte alignment.
>      }
>    }
> 
> I was a bit surprised to see these numbers hardcoded in TargetData
> since everything else is taken from the datalayout string. I was
> wondering what the logic was behind the number 16. Would it make
> sense to derive this number from the other alignments somehow (e.g.
> the maximum preferred alignment across all types). Alternatively
> would it make sense to make it configurable in the datalayout string?
> 
I think that we should make this configurable; I have systems on which
I'd like this to be 32.

 -Hal

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

On Sep 6, 2012, at 8:51 AM, Richard Osborne <richard at xmos.com> wrote:
> I recently noticed that all globals bigger than 16 bytes are being 16 byte
aligned by LLVM (assuming there isn't an explicitly requested alignment).
I'd really rather avoid this, at least for the XCore backend. I tracked this
down to the following code in TargetData.cpp:
> 
>  if (GV->hasInitializer() && GVAlignment == 0) {
>    if (Alignment < 16) {
>      // If the global is not external, see if it is large.  If so, give it
a
>      // larger alignment.
>      if (getTypeSizeInBits(ElemType) > 128)
>        Alignment = 16;    // 16-byte alignment.
>    }
>  }
> 
> I was a bit surprised to see these numbers hardcoded in TargetData since
everything else is taken from the datalayout string. I was wondering what the
logic was behind the number 16. Would it make sense to derive this number from
the other alignments somehow (e.g. the maximum preferred alignment across all
types). Alternatively would it make sense to make it configurable in the
datalayout string?
I don't think that there is any specific logic to it.  It was just a
heuristic that "made sense at the time", not based on any scientific
evaluation.  If you want to raise it to some other arbitrary limit (say 32
bytes) that would be fine given some performance analysis.  If you want to
design a way to express this in target data, please propose a specific way to
model it.

-Chris

On 06/09/12 20:24, Chris Lattner wrote:
> On Sep 6, 2012, at 8:51 AM, Richard Osborne <richard at xmos.com>
wrote:
>
>> I recently noticed that all globals bigger than 16 bytes are being 16
byte aligned by LLVM (assuming there isn't an explicitly requested
alignment). I'd really rather avoid this, at least for the XCore backend. I
tracked this down to the following code in TargetData.cpp:
>>
>>   if (GV->hasInitializer() && GVAlignment == 0) {
>>     if (Alignment < 16) {
>>       // If the global is not external, see if it is large.  If so,
give it a
>>       // larger alignment.
>>       if (getTypeSizeInBits(ElemType) > 128)
>>         Alignment = 16;    // 16-byte alignment.
>>     }
>>   }
>>
>> I was a bit surprised to see these numbers hardcoded in TargetData
since everything else is taken from the datalayout string. I was wondering what
the logic was behind the number 16. Would it make sense to derive this number
from the other alignments somehow (e.g. the maximum preferred alignment across
all types). Alternatively would it make sense to make it configurable in the
datalayout string?
> I don't think that there is any specific logic to it.  It was just a
heuristic that "made sense at the time", not based on any scientific
evaluation.  If you want to raise it to some other arbitrary limit (say 32
bytes) that would be fine given some performance analysis.  If you want to
design a way to express this in target data, please propose a specific way to
model it.
>
> -Chris
I want it to be configurable. On my target there is no advantage to 
aligning anything by more than a 4 bytes - it just wastes space. I'll 
try to put together a proposal for making it possible to set this per 
target.

-- 
Richard Osborne | XMOS
http://www.xmos.com