<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
For two given access sequences we can determine if the accessed<br>
objects are allowed to overlap by the rules of the input<br>
language.</blockquote><div><br></div><div>Sadly, this is where this becomes "unlikely to want to use to replace TBAA", at least for me. It may still be a thing we want anyway.</div><div><br></div><div>This scheme is really an encoding of C/C++ TBAA info so it can be read by LLVM and requires that *LLVM* have some set of rules that it enforces about that scheme.</div><div>But that scheme is still very language specific in how it is used.</div><div>GCC still has something in between this and LLVM, where the language rules are a bit encoded (but not as much as you have).<br></div><div><br></div><div>We (and gcc) have deliberately avoided such schemes, in favor of transforming the info into abstract set trees that then tag loads and stores.</div><div><br></div><div>The encoding of "struct path" tbaa, is just a way of trading space vs time in that encoding.  We trade walking time for the space of transitive closure, etc.</div><div><br></div><div>None of the TBAA in LLVM really has any *real* relation to the original type system rules, and that is deliberate.  I've argued for years that calling it "TBAA" just badly confuses people, and i believe here is a good example :)</div><div><br></div><div>So i don't think what you've written can be used to replace TBAA.</div><div><br></div><div>However, i *do* believe it would be useful to further optimize C and C++ programs in LLVM by using access paths.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div>