[PATCH] D9375: An llvm.noalias intrinsic

[Daniel Berlin via llvm-commits]

On Mon, Aug 15, 2016 at 6:45 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> hfinkel added a comment.
>
> In https://reviews.llvm.org/D9375#516105, @dberlin wrote:
>
> > > In this example the indexing is simple and we'd get the (lack of)
> aliasing anyway, but in the general case the problem is that we lose which
> pointer values are derived from one restrict pointer and which are derived
> from the other once we inline. That's why I have @llvm.noalias return a
> value.
> >
> >
> > Sorry, i misunderstood.
> >  I thought you were saying that llvm.noalias *still* has this problem,
> in the current implementation, and, as i think i pointed out, it should
> not, *because* it returns a value.  It seems like we are in violent
> agreement.
>
>
> Looks that way.
>
> > But that leads me to the other question:
>
> >  What control dependence does it have that requires it be marked as
> argmemonly and not "readnone"?
>
> >  I don't see any tests attached where it would change the semantics if
> they were hoisted to wherever, and i don't see how they could be
> DSE'd/DCE'd if the pointers themselves are not dead :)
>
> >
>
> > So what am i missing?
>
>
> There are no tests because I can't write them yet ;) -- But this certainly
> a good point, and definitely a good thing to discuss. This goes back to an
> earlier part of the description (which I've edited a bit to make the point
> more explicit):
>
> > To summarize from the llvmdev e-mail, the problem underlying (1) is
> that, when using the existing metadata scheme, we cannot differentiate
> between these two after inlining:
>
> >
>
> >   void foo(float * restrict a, float * restrict b) {
>
> >     for (int i = 0; i < 1600; ++i)
>
> >       a[i] = b[i] + 1;
>
> >   }
>
> >
>
> > and:
>
> >
>
> >   void inner(float * restrict a, float * restrict b, int i) {
>
> >     a[i] = b[i] + 1;
>
> >   }
>
> >   void foo(float * a, float * b) {
>
> >     for (int i = 0; i < 1600; ++i)
>
> >       inner(a, b);
>
> >   }
>
> >
>
> > and we currently cheat and assume the former to enable vectorization.
> This is not correct, however, and the underlying issue is that the current
> scheme cannot differentiate directly between:
>
> >
>
> > 1. Does access A alias with access B, both in loop L, within a loop
> iteration
>
> > 2. Does access A alias with the memory accessed by B is any loop
> iteration
>

These are two very different use cases (one is basically aliasing, and the
other is loop dependence analysis).




>
>
> After inlining, the only difference here is that, the two noalias
> intrinsics:
>
> %... = @llvm.noalias(%a, !scope)
> %... = @llvm.noalias(%b, !scope)
>
> will, in the first case, be outside the loop and, in the second case, be
> inside the loop. There's no other difference, but I need to be able to
> distinguish them in order to correctly answer the queries the vectorizer
> wants to make.


IMHO, i would separate these use cases into separate intrinsics.  One which
takes loop info as a parameter (and answers one question), the other does
not (the current noalias).

The one without loop info, can be readnone.
The with loop info, we figure that out :)



> The vectorizer needs to be able to do alias(a[i], b[i], L), where L is the
> loop, and the associated MemLocs have sizes that are infinite (or
> corresponding somehow to the entire range of indices), instead of just
> referring to the individual accesses. If the intrinsics can be hosted out
> of loops, then this won't work.
>
> I can't write a test for this yet because we have no such interface yet.
> Proposing that is what I plan for the next step. Maybe we'll think of a
> better way, and we can make the intrinsics readnone.
>
>
> https://reviews.llvm.org/D9375
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160815/fd6ccf8e/attachment.html>