Demikhovsky, Elena via llvm-dev
2016-Jul-25 14:45 UTC
[llvm-dev] Alias Analysis with inbound GEPs
Hi, 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. Shouldn't the "inbounds" keyword mean that the access to sub-array is also in-bounds? I'm trying to reach "NoAlias" consensus between GEP1 and GEP2. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160725/42aa6d51/attachment.html>
----- Original Message -----> From: "Elena via llvm-dev Demikhovsky" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, July 25, 2016 9:45:55 AM > Subject: [llvm-dev] Alias Analysis with inbound GEPs> Hi,> 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.> 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? -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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160725/c448b8f4/attachment.html>
Demikhovsky, Elena via llvm-dev
2016-Jul-25 19:46 UTC
[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;
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>
Mehdi Amini via llvm-dev
2016-Jul-26 18:37 UTC
[llvm-dev] Alias Analysis with inbound GEPs
> On Jul 25, 2016, at 10:16 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > From: "Elena via llvm-dev Demikhovsky" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, July 25, 2016 9:45:55 AM > Subject: [llvm-dev] Alias Analysis with inbound GEPs > > Hi, > > 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. > Shouldn’t the “inbounds” keyword mean that the access to sub-array is also in-bounds? > No. inbounds applies only to the whole object.Would this proposal help: https://reviews.llvm.org/D22793 <https://reviews.llvm.org/D22793> ? — Mehdi> 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? > > -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 > _______________________________________________ > 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 <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160726/88ecb0b5/attachment.html>