[llvm-dev] RFC: Resolving TBAA issues

[Daniel Berlin via llvm-dev]

>
>
>
> For two given access sequences we can determine if the accessed
> objects are allowed to overlap by the rules of the input
> language.


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.

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.
But that scheme is still very language specific in how it is used.
GCC still has something in between this and LLVM, where the language rules
are a bit encoded (but not as much as you have).

We (and gcc) have deliberately avoided such schemes, in favor of
transforming the info into abstract set trees that then tag loads and
stores.

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.

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 :)

So i don't think what you've written can be used to replace TBAA.

However, i *do* believe it would be useful to further optimize C and C++
programs in LLVM by using access paths.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170817/dc45cc46/attachment.html>