[LLVMdev] Preferred alignment of globals > 16bytes

Richard Osborne
Tue, 18 Sep 2012 10:11:07 -0000

On 07/09/12 18:13, Chris Lattner wrote:
> On Sep 7, 2012, at 8:02 AM, Richard Osborne <richard at xmos.com>
wrote:
>>>> 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.
> Ok, after considering this a bit more, how about we take a different
approach: despite its name, TargetData is really mostly for consumption by the
mid-level optimizers.  getPreferredAlignment is really something that only
TargetLowering[ObjectFile] should be using.  What do you think about sinking
getPreferredAlignment down to it? This will make it much easier to
target-hookize this.
>
> -Chris
Hi Chris,

Sorry for not replying sooner but I've haven't had a chance to look at
this until now. I think your suggestion makes a lot of sense. The
preferred alignment will be a lot easier to change if it is not embedded
in the IR in the form of the target data string. I started trying to
moving the functions to get preferred alignment to TargetLowering but
found there are a few mid-level optimizers that make use of the
preferred alignment. In particular:

* lib/Analysis/ValueTracking.cpp - uses getPreferredAlignment() to
determine number of trailing zeros of the address of a global defined in
the current module.
* lib/Transforms/Utils/InlineFunction.cpp - Uses getPrefTypeAlignment()
to set the alignment of the alloca it introduces when a byval argument
is inlined
* lib/Transforms/IPO/ConstantMerge.cpp - Uses getPreferredAlignment() to
determine the alignment of the merged constant.
* lib/Transforms/Vectorize/BBVectorize.cpp - Depending on what options
are set this pass avoids vectorization if it would introduce loads and
store of less than the alignment returned by getPreferredAlignment().
* lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp -
getPrefTypeAlignment() is used to explictly set the alignment of allocas
with unspecified alignment. Also instcombine tries to enforce preferred
alignment for loads and stores if possible.

Does it seem reasonable to change these to use ABI alignment?

--
Richard Osborne | XMOS