On Sun, Aug 20, 2017 at 2:47 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hello Daniel, > > >>>> the type of (*x) is not compatible with the type of (*b) or, > >>>> recursively, type of b->i. Similarly, the type of (*b) is > >>>> not compatible with (*x) or, recursively, x->i. > >> ... > >>> I think these are interesting interpretations. I'm not sure > >>> i'd personally agree with them (and there are definitely > >>> compilers out there that do not). > >> > >> I wonder how you know that those compilers interpret it > >> differently. If the correct answer for a specific case is > >> "no alias", then reloading of values does not say anything > >> about how authors interpret the cited clause. > >> > >> It's only omission of reloading that does matter. > > > > I know how to produce internal pass dump files and debug output > > from a lot of compilers (XLC, ICC, GCC, etc) > > So i'm staring at the debug output to see what it says. > > Sorry, what I'm trying to determine here is whether observed facts > contradict with either or both of the interpretations. I would appreciate > if you can help me with this so once it is settled, we can proceed with > resolving outstanding TBAA issues. >I really don't have the energy to keep going around on this.> > So once again, if for a specific case the correct answer is "no alias", > then how you know by looking at the generated code, dump files and debug > output what way the authors interpret the clause? >Because i can get the compilers to print, explicitly, what their interpretation of tbaa is.> > You said that there are compilers that definitely do not agree with that > 'a->i' and 'b->i' may not overlap if the types of (*a) and (*b) are not > compatible.This is actually not what i said at all. Because we disagree as to whether they are compatible. You are asserting "compatibility" as if the rules are easy and everyone must agree with your interpretation, but this is not the case. I'm not sure why you find that surprising, it's been the case forever that people disagree on interpretations of these rules.> Can we know how you came to this conclusion? Can you provide specific > examples? > >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. Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170820/c074d178/attachment.html>
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,
--
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>