[LLVMdev] Alignment of pointee

[Frank Winter]

What's the status of providing alignment information for a pointer? Can 
I build an aligned pointer, e.g. a pointer with its pointee 32 bytes 
aligned (float*) and use it as a function's parameter? This would be 
very helpful for optimization passes to get the alignment info on 
load/stores right. Which in turn is a crucial performance feature (and 
on some architectures necessary to generate legal vectorized code).

Best wishes,
Frank


On 03/25/2014 01:29 PM, Hal Finkel wrote:
> ----- Original Message -----
>> From: "Arnaud Allard de Grandmaison" <arnaud.adegm at gmail.com>
>> To: "Hal Finkel" <hfinkel at anl.gov>
>> Cc: "Frank Winter" <fwinter at jlab.org>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
>> Sent: Tuesday, March 25, 2014 12:21:53 PM
>> Subject: Re: [LLVMdev] Alignment of pointee
>>
>>
>> Related to this subject is the __attribute__(aligned(X)) that can be
>> set on a type in C/C++. It is being used when generating the load /
>> stores / memcpy / ... but is lost with respect to the type's
>> attribute. In many a case this could help various analysis or
>> transforms to provide more accurate results when such a type is
>> used. The __builtin_assume_aligned could be an way to solve this.
> Also, FWIW, at least one user of mine is a big fan of Intel's new align_value attribute (which is, at least, discussed here: http://software.intel.com/en-us/articles/data-alignment-to-assist-vectorization), because it plays well with TMP and other related C++ programming techniques (better than __builtin_assume_aligned).
>
>   -Hal
>
>>
>> Cheers,
>> --
>> Arnaud
>>
>>
>>
>> On Tue, Mar 25, 2014 at 4:22 PM, Hal Finkel < hfinkel at anl.gov >
>> wrote:
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: "Frank Winter" < fwinter at jlab.org >
>>> To: llvmdev at cs.uiuc.edu
>>> Sent: Tuesday, March 25, 2014 9:23:59 AM
>>> Subject: Re: [LLVMdev] Alignment of pointee
>>>
>>> On 03/25/2014 10:08 AM, Krzysztof Parzyszek wrote:
>>>> On 3/25/2014 8:53 AM, Frank Winter wrote:
>>>>> One can see that if the initial alignment of the pointee of
>>>>> %arg0
>>>>> was 32
>>>>> bytes and since the vectorizer operates on a loop with a fixed
>>>>> trip
>>>>> count of 4 and the size of double is 8 bytes, the vector loads
>>>>> and
>>>>> stores could be ideally aligned with 32 bytes (which on my
>>>>> target
>>>>> architecture would result in vector loads without additional
>>>>> permutations.
>>>>>
>>>>> Is it somehow possible to achieve this? I am generating the IR
>>>>> with the
>>>>> builder, i.e. I am not coming from C or clang.
>>>> If you are generating the loads and stores, you could just set
>>>> the
>>>> alignment to whatever you want, i.e. 32 bytes in your case.
>>> I can't. Take a look again at the first piece of code. The loads
>>> occur
>>> in the 'inner' loop. Only for the first iteration the alignment of
>>> 32
>>> bytes is true, not for iteration 2, 3 and 4. So, the alignment
>>> information cannot enter at the point of loading. Thus, the idea of
>>> attaching the information right at the pointer's definition, i.e.
>>> as
>>> the
>>> argument.
>> I had a patchset that I had posted for review some months (a year?)
>> ago to implement __builtin_assume_aligned. This ended up
>> side-tracked in a discussion re: generalized invariants. We should,
>> however, certainly revisit this soon.
>>
>> -Hal
>>
>>
>>>> I have wondered about it in a general case, when you simply want
>>>> to
>>>> have an alignment information on the pointer, and not on
>>>> loads/stores. My idea was to invent a builtin, something like
>>>> "assert_aligned", that does nothing, other than manifest the
>>>> alignment
>>>> by the fact of its existence. For example:
>>>> %argp = call i8* llvm.assert.aligned(%arg0, 32)
>>>> would state that the pointer %argp is aligned to 32 bytes, and
>>>> the
>>>> value of it is the same as %arg0 at the place of the "call".
>>>>
>>>> That was a while ago and maybe there are other ways of doing it
>>>> now.
>>> Should be doable this way. Although I am not sure whether a
>>> assertion
>>> or
>>> an annotation would be cleaner.
>>>
>>> There should already be a solution.
>>>> -Krzysztof
>>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>