[PATCH] D28934: Write a new SSAUpdater

[Davide Italiano via Phabricator via llvm-commits]

davide added a comment.

In https://reviews.llvm.org/D28934#651355, @dberlin 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?
>
>
> FWIW: It's been a source of sorrow before.
>  People kind of randomly try to figure out what order to call things in, because it's not clear what the terminology it uses means, nor is it clear what the right sequence necessarily is to get the right result.
>
> As for speed, we wrote an entire separate linear time phi placement pass (see promotememtoreg, and more particularly, idfcalculator) just because the current SSAUpdater was too slow and not easily understandable.
>  It's also used for ADCE and MemorySSA.
>
> This particular patch came about because i needed an SSAUpdater workalike for MemorySSA updating, and i figured, what the heck, might as well see if anyone wants me to replace the existing one while i'm at it.
>  I started with the above, and then modified it for what i needed.
>
> If you stare at this vs the paper vs the existing SSAUpdater, you can clearly see the paper (and this impl) is a slightly more refined version of the renaming algorithm, with a completely different phi insertion scheme shoved on top.
>  (i'm not sure if they both share some common lineage, because otherwise, that's ... yeah)
>
> Our current SSAUpdater tries to iteratively compute dominators, dominance frontiers, and then phi placement for those. It's actually N^3 in the number of variables, and in some cases, badly so.


I don't have any strong comments on the API (yet), I would like to try myself porting a pass as an experiment and see how that feels. I personally think removing the dependency on dom info is already a win per-se, and the code is definitely much smaller/easier to understand than what we currently have (I don't think it will grow enormously if we include SCC, but I may be wrong). 
To sum up, I would like to see this going foward.


https://reviews.llvm.org/D28934