[llvm-dev] Alias Analysis with inbound GEPs

[Hal Finkel via llvm-dev]

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

> From: "Daniel Berlin" <dberlin at dberlin.org>
> To: "Hal J. Finkel" <hfinkel at anl.gov>
> Cc: "Eli Friedman" <eli.friedman at gmail.com>, "llvm-dev"
> <llvm-dev at lists.llvm.org>, "Richard Smith"
> <richard-llvm at metafoo.co.uk>
> Sent: Monday, July 25, 2016 6:58:27 PM
> Subject: Re: [llvm-dev] Alias Analysis with inbound GEPs

> > >
> 
> > > It is actually undefined behavior. This is explicitly called out
> > > in
> > > Annex J.2: "An array subscript is out of range, even if an object
> > > is apparently accessible with the given subscript (as in the
> > > lvalue expression a[1][7] given the declaration int a[4][5]) ".
> > > If
> > > you break it apart into separate steps, the interesting bit is
> > > that the implicit array-to-pointer conversion is not equivalent
> > > to
> > > a cast; "int* b = (int*)a;" is not equivalent to "int* b = *a;",
> > > even though the expressions have the same type and value.
> 
> > >
> 
> > > There currently isn't any way to model the aliasing behavior of
> > > the
> > > address-of operator or array-to-pointer decay in LLVM IR. See
> > > also
> > > http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html .
> 

> > It seems like we might we able to use TBAA metadata with struct
> > field
> > information to get this then.
> 

> Kinda, but the validity of this info does not (and should not) depend
> on TBAA being enabled or not.
Makes sense. For whatever metadata we use to indicate this, ideally its emission should not be tied to whether -fno-strict-aliasing is passed (even if it does use the TBAA metadata infrastructure). 

-Hal 

> > -Hal
> 

> > >
> 
> > > -Eli
> 
> > _______________________________________________
> 
> > 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/c40b1548/attachment.html>