[PATCH] D26438: [Verifier] Add verification for TBAA metadata

Manman Ren via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 10 10:12:35 PST 2016


manmanren added a comment.

In https://reviews.llvm.org/D26438#591415, @sanjoy wrote:

> In https://reviews.llvm.org/D26438#591414, @manmanren wrote:
>
> > > The tag for the load instruction is `!2` whose access type is `!7` == `!{!"float", !5, i64 0}`.
> >
> > !7 is a scalar type node, it is a float, right?
>
>
> Perhaps we are talking past each other, but are you concluding that it is scalar by looking at its name?  I thought the names themselves were not supposed to be significant within the TBAA type system.
>
> Structurally, it is exactly a struct that with a single `char` field.  If I compile
>
>   struct S {
>        int i;
>        float f;
>   };
>  
>   struct S2 {
>        char c;
>   };
>  
>   float f(struct S* s, struct S2* s2) {
>        return s->f + s2->c;
>   }
>
>
> then I get:
>
>   !0 = !{i32 1, !"PIC Level", i32 2}
>   !1 = !{!"clang version 4.0.0 (http://llvm.org/git/clang.git b74377b0a34a33cb3c7b565f0e543cd3e56b3f6b) (llvm/trunk 286280)"}
>   !2 = !{!3, !7, i64 4}
>   !3 = !{!"S", !4, i64 0, !7, i64 4}
>   !4 = !{!"int", !5, i64 0}
>   !5 = !{!"omnipotent char", !6, i64 0}
>   !6 = !{!"Simple C/C++ TBAA"}
>   !7 = !{!"float", !5, i64 0}
>   !8 = !{!9, !5, i64 0}
>   !9 = !{!"S2", !5, i64 0}
>
>
> with `!2` as the access tag for `s->f` and `!8` as the access tag for `s2->c`.  `!2` has `!7` as its access type (which means it must be a scalar type), which is indistinguishable from the struct type node `!9`, except from its name.  Without a priori knowledge of what `"float"` and `"S2"` mean, we can't conclude one way or the other.


I got your point now. In path-aware TBAA, you can't tell if a type node is a struct type node with a single field or a scalar type node by looking at the format of the single MDNode. The formats are uniform to make implementation easy. You can tell from the usage case. If it is the 2nd field of a struct tag node, it  should be a scalar node. Being a scalar node means we don't have to check the offset (the offset should be zero).

Hope this clears things up,
Manman


https://reviews.llvm.org/D26438





More information about the llvm-commits mailing list