[llvm-dev] RFC: Resolving TBAA issues

[Daniel Berlin via llvm-dev]

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 is what happens depends on the
language

But it's definitely the case that, given the above, unless the field layout
is identical,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170820/5dd98401/attachment.html>