[llvm-dev] Restrict qualifier on class members

[Johannes Doerfert via llvm-dev]

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>