search for: tbaa_root

...%1 = load i32* @bbb, !tbaa !2 %2 = add i32 %0, %1 store i32 %2, i32* @aaa, !tbaa !2 ; below line should be eliminated with optimization store i32 %1, i32* @bbb, !tbaa !1 ; <==== WHY optimization CANNOT ELIMINATE this insn? ... !tbaa = !{!0, !1, !2} !0 = metadata !{metadata !"tbaa_root"} !1 = metadata !{metadata !"aaa", metadata !0} !2 = metadata !{metadata !"bbb", metadata !0}

...aaa, !tbaa !2 >> >> ; below line should be eliminated with optimization >> store i32 %1, i32* @bbb, !tbaa !1 ; <==== WHY >> optimization CANNOT ELIMINATE this insn? >> >> ... >> !tbaa = !{!0, !1, !2} >> !0 = metadata !{metadata !"tbaa_root"} >> !1 = metadata !{metadata !"aaa", metadata !0} >> !2 = metadata !{metadata !"bbb", metadata !0} >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu &gt...

...%0, %1 > store i32 %2, i32* @aaa, !tbaa !2 > > ; below line should be eliminated with optimization > store i32 %1, i32* @bbb, !tbaa !1 ; <==== WHY > optimization CANNOT ELIMINATE this insn? > > ... > !tbaa = !{!0, !1, !2} > !0 = metadata !{metadata !"tbaa_root"} > !1 = metadata !{metadata !"aaa", metadata !0} > !2 = metadata !{metadata !"bbb", metadata !0} > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.ui...

...gt;> ; below line should be eliminated with optimization >>> store i32 %1, i32* @bbb, !tbaa !1 ; <==== WHY >>> optimization CANNOT ELIMINATE this insn? >>> >>> ... >>> !tbaa = !{!0, !1, !2} >>> !0 = metadata !{metadata !"tbaa_root"} >>> !1 = metadata !{metadata !"aaa", metadata !0} >>> !2 = metadata !{metadata !"bbb", metadata !0} >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://...

...ttoptr i32 %1 to i32* %3 = load i32* @aaa, align 4, !tbaa !1 store i32 %3, i32* %2, align 4, !tbaa !4 store i32 %3, i32* @bbb, align 4, !tbaa !3 store i32 %1, i32* @sss, align 4, !tbaa !2 ; <== O3 can REMOVE this ret void } !tbaa = !{!0, !1, !2, !3, !4} !0 = metadata !{metadata !"tbaa_root"} !1 = metadata !{metadata !"aaa", metadata !0, i32 0} !2 = metadata !{metadata !"sss", metadata !0, i32 0} !3 = metadata !{metadata !"bbb", metadata !0, i32 0} !4 = metadata !{metadata !"mem", metadata !0, i32 0}

It's hard to say. What you've described sounds close to a neutral type system implemented in metadata. In particular, ". It also defines a set of language-neutral formal rules that LLVM codegen follows to determine whether a given pair of accesses are allowed to overlap by rules of the input language. " and "the base type followed by field descriptors" etc Despite the

...t; [S, S::a, int] > > Similarly to the scalar and struct-path approaches, we consider > every type to be a member of a type group it explicitly refers > to. Here's how the tree that describes relations between type > groups would look like for the example above: > > <tbaa_root> > |- <may_alias> > |- <representation_byte> > |-<structure> > | |- S > |- int > > The <vtable_pointer> group has a special meaning and is used to > describe accesses to virtual table pointers. Similarly, the > <union&...

...>> Similarly to the scalar and struct-path approaches, we consider >> every type to be a member of a type group it explicitly refers >> to. Here's how the tree that describes relations between type >> groups would look like for the example above: >> >> <tbaa_root> >> |- <may_alias> >> |- <representation_byte> >> |-<structure> >> | |- S >> |- int >> >> The <vtable_pointer> group has a special meaning and is used to >> describe accesses to virtual table pointers...

..., align 4, !tbaa !1 > store i32 %3, i32* %2, align 4, !tbaa !4 > store i32 %3, i32* @bbb, align 4, !tbaa !3 > store i32 %1, i32* @sss, align 4, !tbaa !2 ; <== O3 can REMOVE this > ret void > } > > !tbaa = !{!0, !1, !2, !3, !4} > !0 = metadata !{metadata !"tbaa_root"} > !1 = metadata !{metadata !"aaa", metadata !0, i32 0} > !2 = metadata !{metadata !"sss", metadata !0, i32 0} > !3 = metadata !{metadata !"bbb", metadata !0, i32 0} > !4 = metadata !{metadata !"mem", metadata !0, i32 0} >

...t; [S, S::a, int] > > Similarly to the scalar and struct-path approaches, we consider > every type to be a member of a type group it explicitly refers > to. Here's how the tree that describes relations between type > groups would look like for the example above: > > <tbaa_root> > |- <may_alias> > |- <representation_byte> > |-<structure> > | |- S > |- int > > The <vtable_pointer> group has a special meaning and is used to > describe accesses to virtual table pointers. As in the current scheme, th...