[llvm-dev] Alias Analysis with inbound GEPs

[Demikhovsky, Elena via llvm-dev]

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;

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.


 -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<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160725/9cbf3bf5/attachment.html>