[llvm-dev] RFC: Resolving TBAA issues

[Daniel Berlin via llvm-dev]

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.
>

> Even if you have tried to place the fields at the same offset, as you
> have, whether it can disambiguate the accesses can depend on more than just
> TBAA, including alignment rules, etc.
>

You definitely may be able to come up with examples where only tbaa
*should* be active, but i don't think it's really a safe way to go about
testing assumptions about TBAA.
For example, it also assumes no bugs in the other methods of analysis,
which is defintitely not a safe assumption :)

If you only care about the *end result* (IE whether it's allow to say the
accesses overlap) it is generally going to be okay, but again, this assumes
no bug in any implementation

If you want to test tbaa specific things for real, you'd have to print the
tbaa trees and results as gcc sees them, for example.
That's really the only way to be sure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170820/fc3447d9/attachment.html>