----- Original Message ----- > From: "Daniel Berlin" <[email protected]> > To: "Jeroen Dobbelaere" <[email protected]> > Cc: [email protected], "Hal > Finkel" <[email protected]>, [email protected], > "[email protected] Developers" <[email protected]> > 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 < > [email protected] > wrote: > > On Tue, Mar 17, 2015 at 10:24 PM, Daniel Berlin < > > [email protected] > > > 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
