Jan Hubicka wrote: > 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 > I think that at this point, i have been convinced to:
1) use fud's rather than birthpoints because these do keep a slot for the value along each in edge. 2) keep the info on the side (see rsandifors diverging thread). I am not there on keeping extra names on the side. The advantage of the extra names is that it gives you extra freedom. the disadvantage is that either the transformations are more expensive or getting out of the renamed form is expensive. Again, if we have a suite of contiguous converted passes in a row, i could be swayed in the renaming on the side direction, especially if they butted up against the rtl generation step and avoided the out of ssa for the tree ssa. But that is a long time in the future, and i do not see the short term benefits. kenny
