[PATCH] D35741: Add MemorySSA alternative to AliasSetTracker in LICM.

[Daniel Berlin via llvm-commits]

On Wed, Sep 27, 2017 at 9:46 AM, Alina Sbirlea <alina.sbirlea at gmail.com>
wrote:

>
>>> > FWIW I suspect MemorySSAAliasSets will be too slow for use by anything
>>> for
>>> > real.
>>>
>>> I was under the impression is that it should be no worse than
>>> AliasSetTracker,
>>
>>
>> This is true, but AST is badly N^2 already, so realize i'm in the boat of
>> "AST is too slow for anything to use for real".
>>
>> I also very much do not want to see *new* passes using MemorySSAAliasSets
>> to do anything.
>>
>>
>>> and better in some cases (large blocks with very few
>>> memory operations).
>>
>>
>> In the case of promoting loads alone, AST is not necessary at all.
>> In the case of promoting loads and stores, the way our LICM does it means
>> it's still going to be N^2.
>> You will save some walking time.
>>
>> You also end up back in a world where clients are trying to do direct
>> aliasing queries, which sucks.
>>
>>
>>> Otherwise I don't see a reason to do this.
>>>
>>
>> I'm torn.
>> It buys you something, but i also suspect at this level of complexity, we
>> could have just rewritten licm and build a memoryssi or a multi-phi
>> memoryssa or whatever it took to make handling stores fast.
>>
>> Sigh.
>>
>
> Agreed on those points; the patch description talks about the problem with
> promotion.
>
Question is, is it ok to have this functionality checked in as is until a
> rewrite of licm or an alternative for aliasing stores exists?
>
>
I'm not opposed to it if it's actually a win, of course :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170927/f13eb007/attachment.html>