[llvm-dev] Alias Analysis with inbound GEPs

[Hal Finkel via llvm-dev]

----- Original Message -----

> From: "Elena Demikhovsky" <elena.demikhovsky at intel.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Monday, July 25, 2016 2:46:34 PM
> Subject: RE: [llvm-dev] Alias Analysis with inbound GEPs

> > I’m checking aliasing of two pointers:
> 

> > %GEP1 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32
> > 1, i64 %indvars.iv41, i64 %indvars.iv39
> 

> > %GEP2 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32
> > 16
> 

> > The result I got is “PartialAlias” because the indices of the GEP1
> > are variable.
> 
> That seems like a bug. PartialAlias should only be returned when we
> can prove a partial overlap. Otherwise, MayAlias should be returned.
> [Demikhovsky, Elena] There are some comments inside:
> // Statically, we can see that the base objects are the same, but the
> // pointers have dynamic offsets which we can't resolve. And none of
> our
> // little tricks above worked.
> //
> // TODO: Returning PartialAlias instead of MayAlias is a mild hack;
> the
> // practical effect of this is protecting TBAA in the case of dynamic
> // indices into arrays of unions or malloc'd memory.
> return PartialAlias ;
Ah, thanks! That, unfortunately, makes sense. 

> > Shouldn’t the “inbounds” keyword mean that the access to sub-array
> > is
> > also in-bounds?
> 
> No. inbounds applies only to the whole object.
> > I’m trying to reach “NoAlias” consensus between GEP1 and GEP2.
> 
> Did the original code come from C or C++? What are we modeling here?
> [Demikhovsky, Elena] C-code:
> for (m=0; m < params->num; m++) {
> params->a[i][m] = expr;
> }
> %GEP1 is the store for params->a[i][m]
> %GEP2 is the load for params->num.
> The loop is not vectorized due to a possible collision between
> params->num and params->a[i][m]. If I take loading of params->num
> outside the loop, it is vectorized.
> Bounds of array “a” are known at compile time. Limit of “i” and “m”
> are runtime variables.
The problem is, IIRC, it is not undefined behavior to access one structure field by over-indexing an earlier array member. C++ has rules for "safely-derived pointers", and I think they include all pointer arithmetic on addresses from subobjects. If array access is just pointer arithmetic, I'm not sure that helps you as much as you'd like. cc'ing Richard to correct me if necessary. 

Out of curiosity, does SCEVAA get this if you add it to the pipeline before the vectorizer? 

-Hal 

> -Hal
> > Thanks.
> 

> > · Elena
> 

> > ---------------------------------------------------------------------
> 
> > Intel Israel (74) Limited
> 
> > This e-mail and any attachments may contain confidential material
> > for
> 
> > the sole use of the intended recipient(s). Any review or
> > distribution
> 
> > by others is strictly prohibited. If you are not the intended
> 
> > recipient, please contact the sender and delete all copies.
> 

> > _______________________________________________
> 
> > LLVM Developers mailing list
> 
> > llvm-dev at lists.llvm.org
> 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> --

> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160725/7cbd952e/attachment.html>