[llvm-dev] RFC: Resolving TBAA issues

[Hal Finkel via llvm-dev]

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 
> <mailto: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 <mailto: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?

Thanks again,
Hal

>
>     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.
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170820/a55b48dc/attachment.html>