llvm.noalias patches
Hal Finkel via llvm-commits
llvm-commits at lists.llvm.org
Tue Aug 16 13:07:28 PDT 2016
----- Original Message -----
> From: "Hal Finkel via llvm-commits" <llvm-commits at lists.llvm.org>
> To: "Daniel Berlin" <dberlin at dberlin.org>, "chandlerc" <chandlerc at gmail.com>, "Philip Reames"
> <listmail at philipreames.com>, "John McCall" <rjmccall at apple.com>, "David Majnemer" <david.majnemer at gmail.com>
> Cc: "llvm-commits" <llvm-commits at lists.llvm.org>
> Sent: Sunday, July 10, 2016 10:54:53 AM
> Subject: Re: llvm.noalias patches
>
> Hi again,
>
> Thanks to David Majnemer for reviewing many of the patches. David
> made an important observation: Instead of making the "looking
> through the intrinsic" logic about the llvm.noalias intrinsic
> specifically, we could add the 'returned' attribute to the relevant
> parameter and make the patches about looking through calls with a
> 'returned' parameter. I like this approach much better, and I'll
> rework the patches to do this. Also, we don't seem to infer the
> returned attribute; I'll post a patch for that too.
>
> Another change I need to make is that I need to add a second metadata
> parameter to the intrinsic, analogous to the alias.scope metadata we
> have currently. While the semantics as they stand are fine, they're
> not completely sufficient for representing local restrict-qualified
> pointers in C where the pointer variable itself is updated. For
> example, if we have:
>
> void foo(int *a) {
> int *restrict r = a;
> *r++ = 1;
> *r++ = 2;
> --r;
> *r = 3;
> }
>
> With the Clang CodeGen patch, the resulting IR looks like this (after
> optimization):
>
> define void @foo(i32* nocapture %a) local_unnamed_addr #0 {
> entry:
> %0 = tail call i32* @llvm.noalias.p0i32(i32* %a, metadata !1)
> %incdec.ptr = getelementptr inbounds i32, i32* %0, i64 1
> %1 = tail call i32* @llvm.noalias.p0i32(i32* %incdec.ptr, metadata
> !1)
> store i32 1, i32* %0, align 4, !tbaa !4, !noalias !1
> %incdec.ptr1 = getelementptr inbounds i32, i32* %1, i64 1
> %2 = tail call i32* @llvm.noalias.p0i32(i32* %incdec.ptr1, metadata
> !1)
> store i32 2, i32* %1, align 4, !tbaa !4, !noalias !1
> %incdec.ptr2 = getelementptr inbounds i32, i32* %2, i64 -1
> %3 = tail call i32* @llvm.noalias.p0i32(i32* %incdec.ptr2, metadata
> !1)
> store i32 3, i32* %3, align 4, !tbaa !4, !noalias !1
> ret void
> }
>
> which yields this:
>
> NoAlias: store i32 2, i32* %1, align 4, !tbaa !4, !noalias !1 <->
> store i32 1, i32* %0, align 4, !tbaa !4, !noalias !1
> NoAlias: store i32 3, i32* %3, align 4, !tbaa !4, !noalias !1 <->
> store i32 1, i32* %0, align 4, !tbaa !4, !noalias !1
> NoAlias: store i32 3, i32* %3, align 4, !tbaa !4, !noalias !1 <->
> store i32 2, i32* %1, align 4, !tbaa !4, !noalias !1
>
> but that's not correct. The common case is that a restrict-qualified
> pointer is initialized once and then used as a base pointer for
> further computations. However, nothing prevents updating the pointer
> variable to point to an object it pointed to previously. The rule,
> as it stands, is that an access with a noalias scope using a pointer
> based on the intrinsic's return value (with a compatible scope
> parameter) does not alias with an access using a pointer with a
> compatible noalias scope not based on the intrinsics's return value.
> With a second metadata parameter, this will grow to be: ... not
> based on the return value from any intrinsic with the same second
> metadata parameter (the alias.scope parameter). MetadataAsValue
> objects have use lists, so these will be easy to find (the
> implementation already takes advantage of this fact for the existing
> metadata parameter).
To follow-up on this, I realized that I don't need a second metadata parameter for this, but instead, can use the scope parameter; in fact, this is apparently what I had intended when I originally wrote the patches, but there was a bug in the implementation (D9401) which made it not work as intended. I'm going to update that patch such that this problem is fixed.
-Hal
>
> -Hal
>
> ----- Original Message -----
> > From: "Hal Finkel via llvm-commits" <llvm-commits at lists.llvm.org>
> > To: "Daniel Berlin" <dberlin at dberlin.org>, "chandlerc"
> > <chandlerc at gmail.com>, "Philip Reames"
> > <listmail at philipreames.com>, "John McCall" <rjmccall at apple.com>
> > Cc: "llvm-commits" <llvm-commits at lists.llvm.org>
> > Sent: Saturday, July 9, 2016 4:32:34 PM
> > Subject: llvm.noalias patches
> >
> > Hi everyone,
> >
> > After a year's hiatus, I've resumed working on the llvm.noalias
> > patches. In case you don't recall the motivation, and would like
> > to,
> > please see:
> > http://lists.llvm.org/pipermail/llvm-dev/2014-November/078755.html
> > -- I've now rebased and updated the patches in response to the last
> > round of review comments (embarrassingly, from last July). There
> > are
> > currently 19 patches in the set, mostly small. These patches should
> > apply bottom-up (starting from the bottom of the list). I've put a
> > (*) next to the non-trivial ones.
> >
> > Clang:
> >
> > llvm.noalias - Clang CodeGen - check restrict var map only for
> > restrict-qualified lvalues
> > http://reviews.llvm.org/D22189
> >
> > llvm.noalias - Clang CodeGen for local restrict-qualified
> > pointers (*)
> > http://reviews.llvm.org/D9403
> >
> > LLVM:
> >
> > llvm.noalias - don't look through it to simplify GEPs
> > http://reviews.llvm.org/D22184
> >
> > llvm.noalias - isPointerDereferenceable should look through
> > them
> > http://reviews.llvm.org/D9384
> >
> > llvm.noalias - don't prevent loop vectorization
> > http://reviews.llvm.org/D9382
> >
> > llvm.noalias - SCEV can look through it
> > http://reviews.llvm.org/D9381
> >
> > llvm.noalias - Use noalias intrinsics when inlining (and update
> > them when cloning metadata) (*)
> > http://reviews.llvm.org/D9400
> >
> > llvm.noalias - Add IRBuilder support
> > http://reviews.llvm.org/D9378
> >
> > llvm.noalias - Pointer comparison folding should look through
> > them
> > http://reviews.llvm.org/D9387
> >
> > llvm.noalias - computeKnownBits should look through them
> > http://reviews.llvm.org/D9397
> >
> > llvm.noalias - CodeGen support
> > http://reviews.llvm.org/D9380
> >
> > llvm.noalias - CaptureTracking needs to look through them
> > http://reviews.llvm.org/D9386
> >
> > llvm.noalias - handling of dead intrinsics
> > http://reviews.llvm.org/D9376
> >
> > llvm.noalias - don't interfere with llvm.assume
> > http://reviews.llvm.org/D9379
> >
> > llvm.noalias - don't block EarlyCSE
> > http://reviews.llvm.org/D9377
> >
> > llvm.noalias - AA impl (*)
> > http://reviews.llvm.org/D9401
> >
> > llvm.noalias - look through with basicaa
> > http://reviews.llvm.org/D9383
> >
> > llvm.noalias - GetUnderlyingObject intrinsic collection (*)
> > http://reviews.llvm.org/D9398
> >
> > llvm.noalias - add the intrinsic (*)
> > http://reviews.llvm.org/D9375
> >
> > Thanks again,
> > Hal
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-commits
mailing list