[llvm-dev] Alias Analysis with inbound GEPs

[Hal Finkel via llvm-dev]

----- 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>