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>
----- Original Message -----> From: "Mehdi Amini" <mehdi.amini at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Elena Demikhovsky" <elena.demikhovsky at intel.com>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Tuesday, July 26, 2016 1:37:28 PM > Subject: Re: [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: >> > ----- 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. >> Would this proposal help: https://reviews.llvm.org/D22793 ?Yes, it looks like that would help. -Hal> — > 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 > > > 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/20160726/06b0198a/attachment-0001.html>
Demikhovsky, Elena via llvm-dev
2016-Jul-27 15:56 UTC
[llvm-dev] Alias Analysis with inbound GEPs
> Would this proposal help: https://reviews.llvm.org/D22793 ? > Yes, it looks like that would help.Thank you. I’ll try to get more info from the author. Btw, Intel compiler vectorizes this loop and, probably, it is the right thing to do. - Elena From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Tuesday, July 26, 2016 21:54 To: Mehdi Amini <mehdi.amini at apple.com> Cc: Demikhovsky, Elena <elena.demikhovsky at intel.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Alias Analysis with inbound GEPs ________________________________ From: "Mehdi Amini" <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> To: "Hal Finkel" <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> Cc: "Elena Demikhovsky" <elena.demikhovsky at intel.com<mailto:elena.demikhovsky at intel.com>>, "llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Sent: Tuesday, July 26, 2016 1:37:28 PM Subject: Re: [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<mailto:llvm-dev at lists.llvm.org>> wrote: ________________________________ From: "Elena via llvm-dev Demikhovsky" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> To: "llvm-dev" <llvm-dev at lists.llvm.org<mailto: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 ? Yes, it looks like that would help. -Hal — 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<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 _______________________________________________ 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/20160727/1a0a2767/attachment.html>