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

[Daniel Berlin]

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150317/01d51b7e/attachment.html>