[PATCH] D23432: [AliasSetTracker] Degrade AliasSetTracker results when may-alias sets get too large.

[Michael Kuperstein via llvm-commits]

We could drop TBAA (I guess we can keep Scope and NoAlias AAMD), and have
the degraded AST recompute the sets based on GetUnderlyingObject. That is,
partition based on the UO if it isIdentifiedObject, and have a catch-all
set for everything else. This will still catch noalias function parameters
and a few other cases.

But I'm also not sure it's worth the effort, given the eventual move to
MemorySSA(?)

Hal, do you think we can live with full degradation?


On Fri, Aug 12, 2016 at 3:50 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> I suggested this offline on the internal bug as an approach.
> Unioning (literally generating a fake union that has all the original
> members pointers) works sanely in all languages but is tricky and ugly in
> practice (and llvm has no unions anymore).
> You can't pick representatives sanely any other way if you keep tbaa
> because it is not transitive. Same with other types of info other than uo.
>  if you keep those, discovering valid subsets requires querying every pair.
>
> If you drop tbaa, etc, you can partition.
>
> However consensus was long term to use memssa or something else, rather
> than try to devise partitioning for a fundamentally n^2 representation
>
>
> On Fri, Aug 12, 2016, 3:25 PM Hal Finkel <hfinkel at anl.gov> wrote:
>
>> hfinkel added a subscriber: hfinkel.
>> hfinkel added a comment.
>>
>> There might not be anything we can do in general that is better than
>> this, but could we degrade to using summaries of some kind instead of N^2
>> queries. For example, imagine that, in the degraded mode, we represented
>> each set using the result of GetUnderlyingObject and the merged AA
>> metadata. Then we queried using <Ptr, Size, AAMD> vs <UO, UnknownSize,
>> MergedAAMD>, but only once per set, not once per pointer in each set? I'm
>> trying to think of a way to keep getting the easy cases, such as noalias
>> function parameters, even if we degrade on the hard things.
>>
>>
>> https://reviews.llvm.org/D23432
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160812/c37f6b9b/attachment.html>