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
Neil Henning via llvm-dev
2020-Jun-22 08:54 UTC
[llvm-dev] Restrict qualifier on class members
I was originally going to cover this in my now defunct EuroLLVM talk but... we had this exact same problem on Unity's HPC# Burst compiler - how to track no-aliasing on structs. We were constrained in that we had to make it work with LLVM versions all the way back to shipped LLVM 6, so what we did was: - Add module-level metadata that tracked whether a given struct member field was no-alias. - Added our own alias analysis using createExternalAAWrapperPass to register it in the pass pipeline. This allowed us to have zero modifications to LLVM and do something useful with aliasing. The one 'issue' with it is if you have a stack-allocated struct that is SROA'ed you will lose the info that it was a struct, or if you are in a private/internal linkage function that has the struct as an argument, the opt passes can modify the function signature to lose the struct too. We had to do some mitigations here to get perfect aliasing on our usecases. Hope this helps, -Neil. On Mon, Jun 22, 2020 at 5:44 AM Michael Kruse via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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 > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Neil Henning Senior Software Engineer Compiler unity.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200622/1cd5fb25/attachment-0001.html>
Bandhav Veluri via llvm-dev
2020-Jun-22 16:31 UTC
[llvm-dev] Restrict qualifier on class members
Hi Jeroen, That's great! I was trying to use the patch, what's the latest version of the project we could apply it on? Hi Neil, That seems like what I can do as well! Do you happen to have some examples lying around? Maybe a pointer to the planned presentation, if that's okay? Thank you, Bandhav On Mon, Jun 22, 2020 at 1:55 AM Neil Henning <neil.henning at unity3d.com> wrote:> I was originally going to cover this in my now defunct EuroLLVM talk > but... we had this exact same problem on Unity's HPC# Burst compiler - how > to track no-aliasing on structs. We were constrained in that we had to make > it work with LLVM versions all the way back to shipped LLVM 6, so what we > did was: > > - Add module-level metadata that tracked whether a given struct member > field was no-alias. > - Added our own alias analysis using createExternalAAWrapperPass to > register it in the pass pipeline. > > This allowed us to have zero modifications to LLVM and do something useful > with aliasing. The one 'issue' with it is if you have a stack-allocated > struct that is SROA'ed you will lose the info that it was a struct, or if > you are in a private/internal linkage function that has the struct as an > argument, the opt passes can modify the function signature to lose the > struct too. We had to do some mitigations here to get perfect aliasing on > our usecases. > > Hope this helps, > -Neil. > > On Mon, Jun 22, 2020 at 5:44 AM Michael Kruse via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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 >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > -- > Neil Henning > Senior Software Engineer Compiler > unity.com >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200622/1236601d/attachment.html>