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 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 >
On 3/25/2014 9:23 AM, Frank Winter wrote:> > There should already be a solution.That would be quite helpful, especially alignment information for pointers passed into a function. There is "alignment" information for pointer arguments, but it only applied to "byval" pointers, at least back when I was actively interested in it. I'm wondering if there already exists a common approach to this problem. Some kind of metadata perhaps? -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
----- 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
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>