[LLVMdev] Request for comments: TBAA on call

[Daniel Berlin]

So,
1. I'm about to turn into a pumpkin for about 4 weeks, and not really going
to be able to have a serious technical discussion about anything
2. The consensus is very clear that everyone is fine with the design Filip
proposes.

Given that, i'd suggest y'all just move forward as planned :)




On Fri, Oct 11, 2013 at 9:18 AM, Chris Lattner <clattner at apple.com> wrote:

> 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/20131013/208e1d4c/attachment.html>