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