[PATCH] D23032: Rewrite the use optimizer to be less memory intensive and 50% faster.Fixes PR28670

[Sebastian Pop via llvm-commits]

Thanks for the detailed explanation.

On Tue, Aug 2, 2016 at 3:37 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>
> On Tue, Aug 2, 2016 at 1:18 PM, Sebastian Pop <sebpop at gmail.com> wrote:
>>
>> On Tue, Aug 2, 2016 at 3:01 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>> >> Would it be possible to merge the UseOptimizer with the renamePass?
>> > No, because phi nodes are not guaranteed complete until after renaming
>> > is
>> > done.
>>
>> I'm not seeing why having incomplete phis is a problem.
>
>
> The use optimizer and clobber walker know how to walk past phi nodes.
>
> Given
> store a
> if (foo)
> {
> store b
> }
> load a
>
> You will  initially get:
> 1 = memorydef(liveonentry)
> store a
> if (foo)
> {
> 2 = memorydef(1)
> store b
> }
> 3 = memoryphi(1, 2)
> memoryuse(3)
> load a
>
>
> Note that the reaching may-def for the load is 3, but it is not actually
> something that actually clobbers load a.
>
> The use optimizer will walk the paths of the phi node, and determine that
> all paths do not clobber the location "a", and thus, that the correct
> version for the memoryuse is "1".
>
> This cannot happen if not all the paths of the phi node have been filled in.
>
> Ignoring datastructure issues (the renaming algorithm relies on the stack
> being in dominator order):
> Unless the graph is acylic, , it is not possible to come up with an ordering
> where every phi node will have been filled in by the time you hit uses for
> it.
>
> Thus, we do not do use optimization during renaming.
>>
>>
>> >
>> > (more particularly, there is no ordering in which to do renaming that
>> > can
>> > guarantee you don't hit incomplete phi nodes).
>> >
>> > At one point, we had use optimization be part of renaming, but walking
>> > incomplete phi nodes is ....
>> > complicated and not guaranteed to get right answers.
>>
>> I haven't thought enough about merging the rename with the UseOptimizer:
>> it seemed to me that in renamePass you have all the data you need
>> to decide which is the nearest def, and decide on selecting the best
>> name to use.
>
>
> This is not correct due to the above.  Normal SSA renaming algorithm relies
> on the fact that reaching defs are *must*defs, and not may-defs.
> Thus, it does not matter whether the phi node is complete or not, because it
> must be a new ssa version, so you can just push it onto the renaming stack
> when you see it.
>
> This is not true when they are reaching may-defs, and you must walk through
> the stack, or other blocks, to find the right version.
>
>