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

Hal Finkel hfinkel at anl.gov
Sat Nov 15 06:17:07 PST 2014


----- 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 5:31:24 PM
> Subject: Re: [LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias metadata
> 
> You don't have x1 and x2 in your example, assuming you mean:
> 
> int i = 0;
> T A;
> T * y2 = ...
> {
> T * x1 = &A;
> a = x1[i];
> }
> {
> T * restrict x2 = y2;
> b = x2[i];
> }
> 
> then the answer is no, the fact that x2 is restrict qualified does
> not allow us to conclude that &x2[i] and &x1[i] don't alias.
> 
> 
> 
> 
> It should, no? by virtue of x2 being restrict you know that *x2
> doesn't alias A, and *x1 is A.

No, it doesn't. The fact that x2 is restrict does not mean that it does not alias with any other potential accesses from variables live in its block. It only means it does not alias with other accesses with that occur in the block where x2 is live. There is no access to A or x1 in that block, so we can say nothing about it.

> 
> 
> This example is flawed anyway ​because it only has loads,

Yes, but I'm ignoring that for the time being.

> so the
> aliasing isn't that interesting. Something more realistic:
>  
> 
> 

  T A, B;
  T * x1 = .... // either &A or &B
  T * y2 =​ .... // ​​maybe &A
  {
    T * restrict x2 = y2;
​    *​x1 = ...
​    *​x2 = ...
  }

> 
> 
> 
> In this case you'll be able to tell *x1 doesn't alias​ *x2, right?

In this case, yes, we can conclude that x1 and x2 don't alias (because *x1 and *x2 cannot both legally refer to the same object).

> How about if you add restrict to x1?

The conclusion is the same, but if you add restrict to x1, you don't need it on x2. x2 is definitely not based on x1, so if x1 is restrict, then we know that x1 and x2 don't alias.

Thanks again,
Hal

> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory




More information about the llvm-dev mailing list