[llvm-dev] RFC: Resolving TBAA issues

[Daniel Berlin via llvm-dev]

On Sun, Aug 20, 2017 at 9:27 AM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> On 08/20/2017 11:22 AM, Daniel Berlin via llvm-dev wrote:
>
> Sorry, hit send early.
>
>
> On Sun, Aug 20, 2017 at 9:16 AM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
>
>>
>>
>> On Sun, Aug 20, 2017 at 8:54 AM, Ivan A. Kosarev via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hello Daniel,
>>>
>>> > The problem with the way you are trying to show this is that
>>> > there are many ways to prove no-alias, and TBAA is one of them.
>>> > The reason i stare at dump files and debug info is precisely to
>>> > separate the TBAA portion from the rest.
>>>
>>> Makes sense to me. However, for a translation unit like this:
>>>
>>>   struct BUF1 { ... };
>>>   struct BUF2 { ... };
>>>
>>>   int foo(int n, struct BUF1* p, struct BUF2* q) {
>>>      for (int i = 0; i < n; i++)
>>>          p->b1 += q->b2;
>>>      return 0;
>>>   }
>>>
>>> I think we can be sure there are no ways for the compiler to know that
>>> these two accesses do not overlap, except TBAA.
>>
>>
>> This is definitely false in general.
>> Again, speaking about GCC, the logic for whether fields can be accessed
>> is separate from the logic about whether TBAA says fields can be accessed.
>> In some cases the flags to control the logic are both controlled by
>> fstrict-aliasing, but are unrelated to tbaa.
>>
>
> Our current TBAA combines these two things (field-offset-based
> determinations and strictly-type-based rules) into what we call TBAA. This
> proposal does likewise. Are there advantages to splitting them that we
> should consider?
>
>
Yes.
GEP has no relation to original field accesses, as you know (IE we allow
them to access negative offsets, etc)
For a lot of these languages, more than the TBAA rules say that you can't
just  go marching through structures, etc.

We also have cases TBAA cannot disambiguate but C/C++ says the fields can't
overlap. We lack the metadata to correctly say they cannot, because it
cannot be inferred from geps.
(if you search for threads with taewook a while back, you will find some
patches and discussion).


I do not believe the current proposal will solve all of those cases,
particularly when the fields are the same type and structures are
compatible but they cannot overlap in C/C++ anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170820/ba4525b0/attachment.html>