Re: [00/23] Make fwprop use an on-the-side RTL SSA representation

[Michael Matz <matz@suse.de>]

Hello,

On Thu, 26 Nov 2020, Richard Sandiford via Gcc-patches wrote:

> >> The aim is only to provide a different view of existing RTL instructions.
> >> Unlike gimple, and unlike (IIRC) the old RTL SSA project from way back,
> >> the new framework isn't a “native” SSA representation.  This means that
> >> all inputs to a phi node for a register R are also definitions of
> >> register R; no move operation is “hidden” in the phi node.
> > Hmm, I'm trying to parse what the last phrase means.  Does it mean that
> > the "hidden copy" problem for out-of-ssa is avoided?  And if so, how is
> > that maintained over time.  Things like copy-prop will tend to introduce
> > those issues even if they didn't originally exist.
> 
> Yeah, the phi nodes simply say which definition of register R provides
> the value of R on a particular incoming edge.  That definition will
> itself be a phi node for R, an artificial definition of R created by DF
> (e.g. for incoming function arguments or for EH data registers), or an
> actual instruction that sets R.
> 
> In other words, the SSA form is a purely on-the-side thing and the
> underlying RTL instructions are maintained in the same way as normal.
> The SSA form can be deleted at any time without performing a separate
> out-of-ssa step.  In that respect it's different from cfglayout,
> for example.

Hmm, I don't see how that answers Jeffs question, if I got it correctly.  
If I didn't get it correctly let me ask my own version of the question :)

(I haven't studied your implementation in detail, if I had maybe answers 
to the below would become obvious, sorry if so :) )
 
So, you're saying that in your implementation the operands of PHIs can be 
PHIs and real defs.  Further you say nothing about any restriction in RTL 
instruction moving and/or propagation.  So, then let's start with one of 
the prime examples of SSA deconstruction problems, the lost swap, and how 
it comes to be: we start with a swap:

  x = ..., y = ...
  if (cond)
    tmp=x, x=y, y=tmp

(1) into SSA:

  x0 = ..., y0 = ...
  if (cond)
    tmp = x0, x1=y0, y1=tmp;
  x2 = PHI(x0,x1),  y2 = PHI(y0,y1)

(2) copy-prop:

  x0 = ..., y0 = ...
  if (cond)
    ;
  x2 = PHI(x0,y0),  y2 = PHI(y0,x0)

Now you're also saying that the SSA form can simply be deleted without any 
consideration of the parallel copy nature, i.e. no real out-of-ssa phase.  
In the above example that would lead to wrong code, so that can't be it.  
So what in your representation avoids either (1) or (2)?  Do these 
restrictions also work if the above crucial code is within a loop (and 
hence the inputs to PHIs are the PHIs themself, which is the actual 
canonical variant of the lost-copy and swap problems).


Ciao,
Michael.