Re: birthpoints in rtl.

[Jan Hubicka <jh at suse dot cz>]

Hi,
> 
> 1) In ssa, the operands of the phis and the renaming contain
> information.   The operands are paired with the cfg edges that the
> values come in on.   In fud/birthpoints there is no such pairing or
> renaming.   For some problems, like conditional constant, this pairing
> and renaming is what makes the algorithm work.  You actually do not get
> the same answer (you get an inferior but still correct answer) if you do
> not use the pairing and renaming.

I must be quite lost here.  In the non-rewriting SSA (or what I think
FUD chain is) is in my view essentially just alternative representatin
of SSA program.  Instead of having SSA_NAMES and PHI nodes in your IL
directly, they sit on-side datastructure. They hold same information:
version numbers and PHI nodes associated with edges of CFG. For
optimization passes they are however 100% equivalent, just you look at
different places in memory that should be more or less hidden in
abstraction.

Surely with this representation all the SSA analysis algorithms will
work, since what you see is SSA form.  The difference is that you can't
simply use particular SSA name at any place in a program without adding
code to copy the value to register at a place it is defined to be sure
that the original location is not overwritten. 

This is relatively little extra hassle compared to rewritten SSA form
and in the case of conditional constant propagation you don't need to
worry even about that. Not too different on discussions wheteher you
should have on-side CFG and duplicate the info by goto statements or CFG
as part of the IL.

Given that RTL deals with architectural details like partial writes or
hard registers, it seems to make sense to actually target to FUD (or
non-rewritting SSA) rather than trying to adjust RTL to allow SSA in
some form on all those constructs explicitly. Or at least it don't seem
significandly inferrior to me and a lot easier to accomplish.

Honza