[PATCH] D28934: Write a new SSAUpdater

[Matthias Braun via Phabricator via llvm-commits]

MatzeB added a comment.

In https://reviews.llvm.org/D28934#652235, @dberlin wrote:

> As for what's public:
>  The paper comments that for incremental updates, you want readVariableBeforeDef. This is equivalence to getValueAtMiddleOfBlock, which we make public in SSAUpdater.
>
> The paper's API is actually identical to SSAUpdater's old API circa 2010, with the functions renamed.
>  The only difference is the more advanced phi placement algorithms.
>  I think Bob even has most of the marker algorithm right at one point if you go back through the file's history.
>
> I think if we keep going down this route i would change the API.
>  Users shouldn't generally have to care where in the block they are.
>  The real problem on this front is loops.
>
> Given:
> main:
>  def(a)
>  goto loop
>
> loop:
>  use (a)
>  def (a)
>  goto loop or somewhere else
>
> For loop, you need
>
> 1. To call writeVariable of both defs so it's visible to the algorithm, otherwise, it will not get the value over the backedge.
> 2. But ask about the version before the def, because that's where the use is.


Yep, however that soon breaks down as soon as you have more than 1 definition in a block so there isn't a single before/after def anymore.
Just reviewing the libfirm SSA updater, we indeed first introduced all defs to the algorithm (picking the latest one if there are multiple) and then go over all defs/uses in a block from top to bottom.

> I think this should all be hidden, and orderedbb or something used to locate the relative position of the use to the defs.

Yep, some notion of ordering is necessary to get multiple defs/uses in a block "right", finding a way to hide it would be cool.

> (this is what i'm doing for MemorySSA, but memory ssa is easier because we have a single variable and every may-def creates a new version. Thus, i don't even need the user to tell me the defs, i can just find the closest def, etc)


https://reviews.llvm.org/D28934