[llvm-dev] Restrict qualifier on class members

Johannes Doerfert via llvm-dev
Sun, 21 Jun 2020 17:22:18 -0000

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>