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. 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140325/d12aa4bb/attachment.html>
----- 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 > >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
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 >> >>