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

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 2 13:37:59 PDT 2016


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160802/8ec0d4c7/attachment.html>


More information about the llvm-commits mailing list