[LLVMdev] Request for comments: TBAA on call

[Chris Lattner]

On Oct 10, 2013, at 8:53 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> The datastructures and algorithms we have are powerful enough to express these sorts of things, and so long as a frontend abided by the rules, there shouldn't be a problem.
> 
> 
> My concerns are simply that whether designed this way or not, it ends up fairly inconsistent.
> 
> For example, what would the plan be when a frontend does something like clang does now for C/C++ (generate type based TBAA), and also wants to do something like Filip is suggesting (which is also doable on C/C++ with simple frontend analysis)?

There are two possible answers here, depending on the constraints:

1. The frontend author could unify them into one grand tree, like struct field TBAA does.
2. The frontend author could model them as two separate TBAA trees, which the TBAA machinery in LLVM handles conservatively.

The conservative handling of different TBAA trees is critical, because you can LTO (for example) Javascript into C++ code in principle, each using their own TBAA structure.  LLVM is already well set for this, and it isn't an accident :-)


> You also run into issues with the existing metadata on loads/stores in this situation. It's again, entirely possible for a load to conflict with both a tbaa type, and a partitioned heap.    In Filip's scheme, there is no way to represent this. 

I'm not sure what you mean.  The compiler will handle this conservatively.  If you have two different schemas existing in the same application (e.g. due to LTO or due to a language implementing two different non-unified models for some weird reason) then the compiler just doesn't draw any aliasing implications from references using two different schemas.

It is possible in principle to allow a load (for example) to have an arbitrary number of TBAA tags on it, which would solve this (allowing a single load to participate in multiple non-overlapping schemas) but I don't think it is worth the complexity at all.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131010/22023c9e/attachment.html>