[llvm-dev] RFC: Resolving TBAA issues

[Ivan A. Kosarev via llvm-dev]

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. We can also see how 
adding and removing fields affects the resulting code.

For this specific case, do your dump files and debug information say 
that it's not TBAA?

One more thing: mainline LLVM agrees with gcc about this example and 
says "no alias". We have tests to check that we behave this way. The 
reason we fail with it is that we do not identify types properly and 
treat BUF1 and BUF2 as the same type if their definitions look identical.

 > This conversation is becoming both frustrating, energy eating,
 > and honestly, not worth arguing about as there is simply no
 > objective truth to TBAA rules.  So i'm going to bow out.
 > Please feel free to do whatever you think is right, that users
 > are happy with, and that you document and test very well.

My apologies for exhausting you, I didn't mean it. And thanks a lot for 
your help with getting through TBAA details.

Still, I believe that there are formal TBAA rules we can discover and 
analyze to work out an approach to resolving current issues with the 
LLVM TBAA implementation.

As to what to do next, I would appreciate more opinions on this topic 
from other people. Particularly, on this analysis:

http://lists.llvm.org/pipermail/llvm-dev/2017-August/116652.html

Thanks and sorry again,

--