Michael Matz <m...@suse.de> writes: > 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.
Specifically real defs of the same register (or memory, for memory phis). > Further you say nothing about any restriction in RTL > instruction moving and/or propagation. The RTL SSA form doesn't add any extra restrictions beyond those that apply to non-SSA RTL passes. But it also doesn't take any restrictions away. In other words, the changes that RTL SSA passes make to RTL instructions are the same as those that non-SSA RTL passes would make. The SSA form is just there to make it easier to process use-def chains (and also to process live ranges, to a limited extent). > 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) So the point is that this isn't what the RTL would look like even when using RTL SSA. Putting y0 in x2 PHI and x0 in the y2 PHI is representationally invalid. Like I say, this isn't a “native” SSA form: it's just using SSA constructs to represent dataflow in normal RTL. > 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). Hope the above answers this. Using the notation above, every input to an xn PHI always has the form xi. I don't think it's worth having a native SSA form in RTL given that we already have one in gimple. It would just lose some low-level details that are (IMO) important for RTL, and that distinguish RTL from gimple, such as the need for a temporary register in your swap example. Thanks, Richard
