[LLVMdev] Request for comments: TBAA on call

[Chris Lattner]

On Oct 11, 2013, at 12:16 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
> 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.
> 
> I would be impressed if you could unify the output of something like andersens, and something like the current nested TBAA structure, without massive loss of precision.

To clarify, I have no desire (and I think it would be completely the wrong approach) to represent "points-to" information into the TBAA metadata.   Regardless of whether its unification or subset based, this is just *not* the right approach for points-to information.

I was referring to a frontend that wanted to express source-level aliasing properties through two different TBAA trees for some reason.

> 
> 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.
> 
> I mean it's not possible, in this scheme, to specify both to be used for disambiguation.
> 
> Right now, you get *one* tbaa tag on the load.
> So you have to choose which tree you use if you want if you choose option #2 above.
> 
> You always have to choose one or the other, or else the lose the disambiguation.

Correct.  This is possible to extend our model to allow multiple tags on loads and stores, but I know of no use case for it, so there is no reason to add the complexity at this point.

> 
>  The compiler will handle this conservatively.
> 
> Only if you drop the tags/disambiguation capability from most things, or i'm seriously confused.
> 
> let's take the following not-quite llvm-ir, but close enough.
> 
> 
> !tbaa tree
> 
> 0 -> everything
> 
> 1 (parent 0) -> int
> 2 (parent 0 -> heap a
> 
> load <whatever> , !tbaa 1
> 
> call !tbaa.read 2
> 
> 
> Note: You can't specify tbaa.read 2, 1 (at least as proposed).
> the current machinery will say the call and the load never conflict.

I thought you had a general objection about representing the heap partitioning that javascript needs with TBAA information.

For calls, I agree that you want a mod/ref *set* of different tbaa tags.  Having a single tag would definitely not be enough.  Perhaps this is why we're talking across each other.  I thought you were talking about multiple tags on load/store, and didn't realize you were talking about calls.  For calls, I definitely agree you want a set of tags, ideally with "mod, ref, mod+ref" information for each tag.

> I also can't think of a combined tree that would work without massive precision loss.

I agree with you in the case of calls.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131011/006fecae/attachment.html>