[LLVMdev] PR400 - alignment for LD/ST
christopher.lamb at gmail.com
Mon Apr 2 11:10:42 PDT 2007
On Apr 2, 2007, at 2:01 PM, Chris Lattner wrote:
> On Mon, 2 Apr 2007, Christopher Lamb wrote:
>> Here's a related question. It seems that there might be a benefit
>> in knowing
>> about two alignment values for a load/store. The alignment of the
>> itself, but potentially also the alignment of the base pointer
>> used for the
>> load/store. Having an alignment attribute on pointer types would
>> solve both
>> these issues, but having a single alignment attribute on loads/stores
>> doesn't. This would lead me to propose having an alignment
>> attribute for
>> getelementptr. Thoughts?
> I may be misunderstanding, if so, please correct me. However, I think
> you're trying to bring addressing modes into this. Many targets
> "reg+immediate" addressing modes... I assume you're trying to get an
> alignment value for the 'reg' part, without the "immed" part?
You are correct.
> This approach would have a couple of problems. Instead, if you
> wanted a
> more general alignment model, I'd suggest going for representing
> alignments as "offset from alignment".
> In this model, you represent each alignment value as a pair
> where offs is always less than align. This allows you to say that
> load is 2 bytes away from a 16-byte aligned pointer" for example.
Shouldn't it be, "this load is a multiple of 2-bytes away from a 16-
byte aligned pointer", isn't that more general?
The case I'm dealing with directly pertains to indexing arrays that
are themselves aligned. This information allows loads/stores (say in
an unrolled loop) to be coalesced as they can be determined to
reference to the same memory.
This would mean that the alignment of the load itself will be align
if no offset is provided and min(align, offs) if an offset alignment
is provided. Do you think it will be difficult for the front-end to
provide these two alignments?
Also, I've noticed that a some transformations on Loads/Stores don't
preserve either volatility or alignment information.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev