[LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias metadata

Raul Silvera rsilvera at google.com
Fri Nov 14 10:15:51 PST 2014


Thanks, Hal... Let me stay on the first question for now.

If we take your example and remove the first restrict:
  T A;
  T * y1 = ..., y2 = ...
  {
    T * x = &A;
    a = x[i];
  }
  {
    T * restrict x = y2;
    b = x[i];
  }

Will we assert that *x1 and *x2 do not alias each other? If so, why is it
OK here and not if the first one is restrict? I believe from a language
perspective you just need the bottom restrict to make the guarantee.

On Fri Nov 14 2014 at 9:48:42 AM Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Raul Silvera" <rsilvera at google.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "Chandler Carruth" <chandlerc at google.com>, "LLVM Developers Mailing
> List" <llvmdev at cs.uiuc.edu>
> > Sent: Friday, November 14, 2014 10:34:39 AM
> > Subject: Re: [LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias
> metadata
> >
> >
> >
> > Hal, a couple of questions:
> >
> >
> > 1. Do you preserve alias to stores+loads derived through a different
> > @llvm.noalias call which has different scope metadata? Couldn't that
> > be treated similarly to S+Ls derived from other identified objects?
>
> From a different scope? No. Here's why:
>
>   int i = ...;
>   T a, b;
>
> which becomes:
>
>   int i = ...;
>   T a, b;
>   T * y1 = ..., y2 = ...
>   T * x1 = @llvm.noalias(y1, !scope1);
>   a = x1[i]; // alias.scope !scope1
>   T * x2 = @llvm.noalias(y2, !scope2);
>   b = x2[i]; // alias.scope !scope2
>
> but can we assume that 'x1[i]' does not alias with 'x2[i]'? No.
>
> Now one possible design here is to solve this problem by mutual dominance,
> but to do that, we'd need to make code motion around the @llvm.noalias
> calls highly restricted. I'd like to allow for as much data motion as
> possible.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141114/05f4615c/attachment.html>


More information about the llvm-dev mailing list