[llvm-dev] RFC: Resolving TBAA issues
Daniel Berlin via llvm-dev
llvm-dev at lists.llvm.org
Sat Aug 19 13:36:22 PDT 2017
On Sat, Aug 19, 2017 at 1:04 PM, Ivan A. Kosarev via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
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.
> Would you mind if we proceed with concrete examples from this point?
>
> I don't believe we are ever going to agree, so i'm not sure there is a
point.
> These two accesses are allowed overlap as the type of b->a is compatible
> with the type of (*x).
Errr, previously you split the access into one, and said it's about whether
each part is compatible.
So i assume then you also believe *b is compatible with *x here?
> I should admit I don't see what makes this case special. Can you elaborate
> please?
>
Honestly? I don't find your answers that consistent with the rules.
I do not feel you have explained *why* you find these types "incompatible"
(the rules only talk about direct compatibility as one option).
You have just asserted they are so.
But i also don't really have a strong desire to argue about TBAA, as people
often do not agree on the answers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170819/cf1ab8d7/attachment.html>
More information about the llvm-dev
mailing list