> 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.
The names are equivalent to UD pointers: Either you can have version names or just coinsider the destination of UD pointer to be the destination. Or am I still missing a point? > > 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 Generating RTL and building FUD based on existing tree-SSA is doable. I am not sure how practical however. The value can be to have a means of transfering fine grained info to RTL level. Definitly not step we want to make tomorrow ;) I guess we can just stay rebuilding FUDs as we rebuild DU/UD on RTL now. It should not be any more expensive, I hope (definitly it should not have the extreme side cases as DU/UD has, I am not sure how average construction time for FUDs/SSA compare to DU/UD construction. Algorithms seems comparably complex to my eyes. Gradually we update passes to maintain the info. It is all bit slippery on RTL level since most transformation go through RTL emit machinery that is allowed to introduce fancy things, clobber registers, add temporaries and do all that stuff. I believe that FUD on hard regs is doable and practical: I don't see how the rewriting SSA problems hit by RTL-SSA project map here and overall I believe the basic disapointment lesson from RTL-SSA project was not SUBREGs/STRICT_LOW_PARTs and other isues, but the fact that RTL is that hard to modify: everything you do go through target validation machinery or expansion and can behave irregularly that does not play well with standard optimization algorithms plus there are ugly things like libcall or other notes that was a lot more important in GCC of RTL-SSA project time. So at the end adding sane analysis framework didn't let you to write easy high level transformations RTL-SSA was originally intended for. With Gimple optimizer in place, we are however not targetting this kind of stuff on RTL anymore. We want sane dataflow info for guiding basic stuff (DCE/CCP/register allocation/GCSE). Honza > not see the short term benefits. > > kenny
