Re: birthpoints in rtl.

[Jan Hubicka <hubicka at ucw dot cz>]

Hi,
as discussed briefly on IRC yesterday, I would be very happy to see
current DU/UD infrastructure changed to FUD chains (or on side SSA
form). This way it will be more symmetric to how tree level virtual
operands are handled and will hopefully make whole compiler more
standard and easier to follow.
> 
> >Thanks for the quick response.  As it turns out, the libcall issue will
> >soon be gone, as bonzini will be deleting them.  We have finally
> >overcome that issue. 
> 
> Not really.  There seems always to be something that prevents them from 
> being deleted, and I have no time to spend on GCC at work right now.  I 
> believe Steven Bosscher has more detail on that than I do.
> 
> But I don't think that they influence birthpoints, which seems to be 
> just a way to factor use-def/def-use chains (yes, analogy with the name 
> of FUD chains is not by chance) without introducing phi functions.  phi 
> operands would be a birthpoint's reaching defs, in practice, right?

Yes, I do believe that wast majority of DU/UD code can stay as it is.
We just need to introduce the PHI nodes, either in a way Gimple does
that in separate section of CFG or as real RTL noop moves (or we can
even have RTL PHI code that would behave same way as USEs does
not, ie bypass machine validation issues).

We can change the DU/UD representation to allow only one DEF except for
the PHI nodes where multiple DEFs will need also the mapping to edges.

> 
> >I believe that what i am proposing is actually currently called (or at
> >least related to) factored use def chains,
> 
> FUD chains are basically SSA without subscripts -- and hence, without 
> overlapping live ranges.
> 
> >>Ian is right, subregs were a problem (and strict_low_part).  I don't
> >>recall offhand if it was "normal" subregs or paradoxicals (or both)
> >>that caused pain.
> 
> I doubt paradoxical subregs cause any pain.
> 
> >>I haven't looked at the PR in question, but you could probably punt
> >>SUBREGs and get the benefits you want for real code on most ports.
> >>Yes, someone can (and probably will) contrive an example which does
> >>the same thing as your problem PR, but which is littered with SUBREGs
> >>in all the "right" places.  But the question I think we have to ask at
> >>that point is whether or not such code is something we absolutely have
> >>to worry about from a compile-time or optimization standpoint.
> 
> Agreed.

libcalls, hard registers and operations on parts of registers (subregs,
strict low parts etc) as well as match dup are problem for real
rewriting SSA form, but not big deal to handle with FUD, since we have
separate input/output name and they are all just read-modify-write
operations from dataflow POV.

Honza
> 
> Paolo