[cfe-dev] [PATCH] Fix for bug 21725: wrong results with union and strict-aliasing

Hal Finkel hfinkel at anl.gov
Tue Mar 17 17:04:35 PDT 2015


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

> From: "Daniel Berlin" <dberlin at dberlin.org>
> To: "Jeroen Dobbelaere" <jeroen.dobbelaere at gmail.com>
> Cc: reviews+D8056+public+7b63cedb34d51bb1 at reviews.llvm.org, "Hal
> Finkel" <hfinkel at anl.gov>, cfe-commits at cs.uiuc.edu,
> "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>
> Sent: Tuesday, March 17, 2015 5:59:18 PM
> Subject: Re: [PATCH] Fix for bug 21725: wrong results with union and
> strict-aliasing

> On Tue, Mar 17, 2015 at 3:41 PM, Jeroen Dobbelaere <
> jeroen.dobbelaere at gmail.com > wrote:

> > On Tue, Mar 17, 2015 at 10:24 PM, Daniel Berlin <
> > dberlin at dberlin.org
> > > wrote:
> 

> > > [..]
> > 
> 
> > > Note that In !41, we loose the information about the 'short'
> > > member.
> > 
> 

> > > I would start here :)
> > 
> 

> > > You should make it produce info about all the members.
> > 
> 

> > Sounds reasonable.
> 

> > > > [..]
> > > 
> > 
> 
> > > > One issue with getting array accesses right that I see, is that
> > > > the
> > > > 'offset' field can suddenly be variable.
> > > 
> > 
> 

> > > Not really. You can't say where it points, so the range would be
> > > "everything" anyway.
> > 
> 
> > > You should just say it accesses the entire array (but not
> > > anything
> > > else).
> > 
> 

> > In order to provide as detailed and accurate feedback as possible,
> > my
> > current changes to the tbaa analysis
> 
> > take the (location) access size into account. This is because the
> > tbaa path information itself does not
> 
> > contain direct size information, only offsets.
> 

> > Is there today already a way how such variable array access can be
> > described ?
> 
> You can't do this sanely without a lot of work, because it can
> overlap multiple actual variables and structs.

> The way we did this in GCC was to just dynamically evaluate which
> parts of which structures it could access, and then combine all
> those types.

> > Is there a way to describe that we have an array of a certain
> > type/size in the tbaa struct ?
> 

> you can certainly describe it, but it would require metadata
> structure changes.
FWIW, I'm not opposed to such changes. We might, however, want to design them in such a way that the explicit size information can be omitted when it can be inferred from the offsets (to reduce the size of the metadata in the common case). 

-Hal 

> > Just looking at containment of types gives some information and
> > will
> > in certain cases fix incorrect behavior, but it will also result in
> > performance degradation (due to more 'MayAliases') if offsets can
> > not be taken into account in the way they are used today.
> 

> > Greetings,
> 

> > Jeroen Dobbelaere
> 

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150317/ba4daeb5/attachment.html>


More information about the cfe-dev mailing list