Bandhav Veluri via llvm-dev
2020-Jun-21 16:56 UTC
[llvm-dev] Restrict qualifier on class members
Hi,
I'm trying to abstract some special pointers with a class, like in the
example program below:
1 #define __remote __attribute__((address_space(1)))
2 #include <stdint.h>
3
4 __remote int* A;
5 __remote int* B;
6
7 class RemotePtr {
8 private:
9 __remote int* __restrict a;
10
11 public:
12 RemotePtr(__remote int* a) : a(a) {}
13
14 __remote int& at(int n) {
15 return a[n];
16 }
17 };
18
19 int main(int argc, char** argv) {
20 RemotePtr a(A);
21 RemotePtr b(B);
22
23 #pragma unroll 4
24 for(int i=0; i<4; ++i) {
25 a.at(i) += b.at(i);
26 }
27
28 return 0;
29 }
It's given that pointer a, in each object of the class RemotePtr, is the
only pointer that can access the array pointed by it. So, I tried __remote
int* __restrict a; (line 9) construct to tell Clang the same. This doesn't
seem to work and I see no noliass in the generated IR. Specifically, I want
lines 23-26 optimized assuming no aliasing between A and B. Any reason why
Clang shouldn't annotate memory accesses in lines 23-26 with noaliass
taking line 9 into account?
The higher level problem is this: is there a way to compile lines 23-26
assuming no aliasing between A and B, by just doing something in the
RemotePtr class (so that main is clear of ugly code)? If that's not
possible, is there a way to tell Clang that lines 23-26 should assume no
aliasing at all, by some pragma?
Thank you,
Bandhav
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200621/7971fe25/attachment.html>
Johannes Doerfert via llvm-dev
2020-Jun-21 17:22 UTC
[llvm-dev] Restrict qualifier on class members
Hi Bandhav, Jeroen Dobbelaere (CC'ed) is currently working on support for restrict qualified local variables and struct members. The patches exist but are not merged yet. If you want to give it a try apply https://reviews.llvm.org/D69542. Initially I could only think of this solution for your problem: https://godbolt.org/z/6WtPXJ Michael (CC'ed) might now another annotation to get `llvm.access` metadata for the loop, which should do what you intend. Cheers, Johannes On 6/21/20 11:56 AM, Bandhav Veluri via llvm-dev wrote:> Hi, > > I'm trying to abstract some special pointers with a class, like in the > example program below: > > 1 #define __remote __attribute__((address_space(1))) > 2 #include <stdint.h> > 3 > 4 __remote int* A; > 5 __remote int* B; > 6 > 7 class RemotePtr { > 8 private: > 9 __remote int* __restrict a; > 10 > 11 public: > 12 RemotePtr(__remote int* a) : a(a) {} > 13 > 14 __remote int& at(int n) { > 15 return a[n]; > 16 } > 17 }; > 18 > 19 int main(int argc, char** argv) { > 20 RemotePtr a(A); > 21 RemotePtr b(B); > 22 > 23 #pragma unroll 4 > 24 for(int i=0; i<4; ++i) { > 25 a.at(i) += b.at(i); > 26 } > 27 > 28 return 0; > 29 } > > It's given that pointer a, in each object of the class RemotePtr, is the > only pointer that can access the array pointed by it. So, I tried __remote > int* __restrict a; (line 9) construct to tell Clang the same. This doesn't > seem to work and I see no noliass in the generated IR. Specifically, I want > lines 23-26 optimized assuming no aliasing between A and B. Any reason why > Clang shouldn't annotate memory accesses in lines 23-26 with noaliass > taking line 9 into account? > > The higher level problem is this: is there a way to compile lines 23-26 > assuming no aliasing between A and B, by just doing something in the > RemotePtr class (so that main is clear of ugly code)? If that's not > possible, is there a way to tell Clang that lines 23-26 should assume no > aliasing at all, by some pragma? > > Thank you, > Bandhav > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200621/0149c66b/attachment.html>
Michael Kruse via llvm-dev
2020-Jun-22 04:43 UTC
[llvm-dev] Restrict qualifier on class members
Unfortunately https://llvm.org/docs/LangRef.html#llvm-loop-parallel-accesses-metadata is not a solution here. A loop-parallel access does not imply non-aliasing. The obvious case is when only reading from a location, but even when a location is written to I'd be careful to deduce that they do not alias since it might be a "benign data race" or the value never used. Additionally, LLVM's loop unroller is known to now handle noalias metadata correctly as it just copies it. There has been a discussion here: http://lists.llvm.org/pipermail/llvm-dev/2020-May/141587.html Michael Am So., 21. Juni 2020 um 12:24 Uhr schrieb Johannes Doerfert via llvm-dev <llvm-dev at lists.llvm.org>:> > Hi Bandhav, > > > Jeroen Dobbelaere (CC'ed) is currently working on support for restrict qualified local variables and struct members. > > The patches exist but are not merged yet. If you want to give it a try apply https://reviews.llvm.org/D69542. > > > Initially I could only think of this solution for your problem: https://godbolt.org/z/6WtPXJ > > Michael (CC'ed) might now another annotation to get `llvm.access` metadata for the loop, which should do what you intend. > > > Cheers, > > Johannes > > > On 6/21/20 11:56 AM, Bandhav Veluri via llvm-dev wrote: > > Hi, > > I'm trying to abstract some special pointers with a class, like in the > example program below: > > 1 #define __remote __attribute__((address_space(1))) > 2 #include <stdint.h> > 3 > 4 __remote int* A; > 5 __remote int* B; > 6 > 7 class RemotePtr { > 8 private: > 9 __remote int* __restrict a; > 10 > 11 public: > 12 RemotePtr(__remote int* a) : a(a) {} > 13 > 14 __remote int& at(int n) { > 15 return a[n]; > 16 } > 17 }; > 18 > 19 int main(int argc, char** argv) { > 20 RemotePtr a(A); > 21 RemotePtr b(B); > 22 > 23 #pragma unroll 4 > 24 for(int i=0; i<4; ++i) { > 25 a.at(i) += b.at(i); > 26 } > 27 > 28 return 0; > 29 } > > It's given that pointer a, in each object of the class RemotePtr, is the > only pointer that can access the array pointed by it. So, I tried __remote > int* __restrict a; (line 9) construct to tell Clang the same. This doesn't > seem to work and I see no noliass in the generated IR. Specifically, I want > lines 23-26 optimized assuming no aliasing between A and B. Any reason why > Clang shouldn't annotate memory accesses in lines 23-26 with noaliass > taking line 9 into account? > > The higher level problem is this: is there a way to compile lines 23-26 > assuming no aliasing between A and B, by just doing something in the > RemotePtr class (so that main is clear of ugly code)? If that's not > possible, is there a way to tell Clang that lines 23-26 should assume no > aliasing at all, by some pragma? > > Thank you, > Bandhav > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Jeroen Dobbelaere via llvm-dev
2020-Jun-22 08:50 UTC
[llvm-dev] Restrict qualifier on class members
Hi Bandhav,> It's given that pointer a, in each object of the class RemotePtr, is the> only pointer that can access the array pointed by it. So, I tried __remote> int* __restrict a; (line 9) construct to tell Clang the same. This doesn'tThis is indeed the correct way to interpret the restrict annotation. With the full restrict patches, this code is vectorized to: ; Function Attrs: norecurse nounwind uwtable define dso_local i32 @main(i32 %argc, i8** nocapture readnone %argv) local_unnamed_addr #0 !noalias !2 { entry: %0 = load i32 addrspace(1)*, i32 addrspace(1)** @A, align 8, !tbaa !5, !noalias !9 %1 = load <4 x i32> addrspace(1)*, <4 x i32> addrspace(1)** bitcast (i32 addrspace(1)** @B to <4 x i32> addrspace(1)**), align 8, !tbaa !5, !noalias !9 %2 = load <4 x i32>, <4 x i32> addrspace(1)* %1, align 4, !tbaa !13 %3 = bitcast i32 addrspace(1)* %0 to <4 x i32> addrspace(1)* %4 = load <4 x i32>, <4 x i32> addrspace(1)* %3, align 4, !tbaa !13 %5 = add nsw <4 x i32> %4, %2 %6 = bitcast i32 addrspace(1)* %0 to <4 x i32> addrspace(1)* store <4 x i32> %5, <4 x i32> addrspace(1)* %6, align 4, !tbaa !13 ret i32 0 } Greetings, Jeroen Dobbelaere From: Johannes Doerfert <johannesdoerfert at gmail.com> Sent: Sunday, June 21, 2020 19:22 To: Bandhav Veluri <bandhav.veluri00 at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org> Cc: Jeroen Dobbelaere <dobbel at synopsys.com>; Kruse, Michael <michael.kruse at anl.gov> Subject: Re: [llvm-dev] Restrict qualifier on class members Hi Bandhav, Jeroen Dobbelaere (CC'ed) is currently working on support for restrict qualified local variables and struct members. The patches exist but are not merged yet. If you want to give it a try apply https://reviews.llvm.org/D69542<https://urldefense.com/v3/__https:/reviews.llvm.org/D69542__;!!A4F2R9G_pg!Pjti9CWiUzKTT2q0q845iVs3V_xoVOwy0jfjcORjShtA3AY2yyxst36qT7R2WV_qjrJfjPOL$>. Initially I could only think of this solution for your problem: https://godbolt.org/z/6WtPXJ<https://urldefense.com/v3/__https:/godbolt.org/z/6WtPXJ__;!!A4F2R9G_pg!Pjti9CWiUzKTT2q0q845iVs3V_xoVOwy0jfjcORjShtA3AY2yyxst36qT7R2WV_qjiZydN-O$> Michael (CC'ed) might now another annotation to get `llvm.access` metadata for the loop, which should do what you intend. Cheers, Johannes On 6/21/20 11:56 AM, Bandhav Veluri via llvm-dev wrote: Hi, I'm trying to abstract some special pointers with a class, like in the example program below: 1 #define __remote __attribute__((address_space(1))) 2 #include <stdint.h> 3 4 __remote int* A; 5 __remote int* B; 6 7 class RemotePtr { 8 private: 9 __remote int* __restrict a; 10 11 public: 12 RemotePtr(__remote int* a) : a(a) {} 13 14 __remote int& at(int n) { 15 return a[n]; 16 } 17 }; 18 19 int main(int argc, char** argv) { 20 RemotePtr a(A); 21 RemotePtr b(B); 22 23 #pragma unroll 4 24 for(int i=0; i<4; ++i) { 25 a.at(i) += b.at(i); 26 } 27 28 return 0; 29 } It's given that pointer a, in each object of the class RemotePtr, is the only pointer that can access the array pointed by it. So, I tried __remote int* __restrict a; (line 9) construct to tell Clang the same. This doesn't seem to work and I see no noliass in the generated IR. Specifically, I want lines 23-26 optimized assuming no aliasing between A and B. Any reason why Clang shouldn't annotate memory accesses in lines 23-26 with noaliass taking line 9 into account? The higher level problem is this: is there a way to compile lines 23-26 assuming no aliasing between A and B, by just doing something in the RemotePtr class (so that main is clear of ugly code)? If that's not possible, is there a way to tell Clang that lines 23-26 should assume no aliasing at all, by some pragma? Thank you, Bandhav _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!A4F2R9G_pg!Pjti9CWiUzKTT2q0q845iVs3V_xoVOwy0jfjcORjShtA3AY2yyxst36qT7R2WV_qjlOsJRhJ$> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200622/2c1adf9c/attachment-0001.html>