On 11/27/20 9:31 AM, Richard Sandiford via Gcc-patches wrote:
> 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.
It appears that the PHI arguments have to be different instances of the
result. So the case above can't happen, which helps, but I'm not sure
it's necessarily sufficient to avoid all the problems in this space.
IIRC you can get into a similar scenario by transformations that result
in overlapping lifetimes for different instances of the same object.
They didn't necessarily overlap when the SSA form was created, but may
after things like CSE or copy propagation.
The fact that passes don't directly manipulate the PHIs definitely helps
as well. But I've still got some reading to do in this space to refresh
my memory of the issues.
jeff
