[PATCH] D28934: Write a new SSAUpdater

[Daniel Berlin via Phabricator via llvm-commits]

dberlin added a comment.

In https://reviews.llvm.org/D28934#655907, @mehdi_amini wrote:

> In https://reviews.llvm.org/D28934#651323, @sanjoy wrote:
>
> > I've never really heard people complain about our current `SSAUpdater` (about it being too slow or difficult to use) -- well except in this review :).  Is there a specific problem you're trying to address with this?
>
>
> One data point : in https://llvm.org/bugs/show_bug.cgi?id=16756 we have a test case where JumpThreading is taking 30% of the total time of a clang -O3 compilation. 
>  One large issue was that we were spending a lot of time in SSAUpdater (Duncan mentions in this PR that the bottleneck is SSAUpdater).
>
> When I looked at it, it seemed to me that we were constantly rebuilding the DominatorTree inside the SSAUpdater over and over for each and every replacement, while it seemed possible to build one up front and reusing it.


It also rebuilds the dominance frontiers. The problem with this is that the answer changes depending on the definition blocks you choose.  We have a minimal linear time calculator (not used in the current updater, but used by PromoteMemToReg now) , but it's still linear-time per variable worst case.  It does do tricks to minimize the work it does.
Before i started down the path of the current algorithm, i also read all the latest multi-variable phi placement algorithms.

In practice, this seemed the easiest starting point, as the "share work between frontier calculation" algorithms get fairly complicated.


https://reviews.llvm.org/D28934