[llvm-dev] Restrict qualifier on class members
Bandhav Veluri via llvm-dev
llvm-dev at lists.llvm.org
Mon Jun 22 09:31:34 PDT 2020
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>
More information about the llvm-dev
mailing list