This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: birthpoints in rtl.


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]