This is the mail archive of the gcc-patches@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: [patch] Lno branch merge part 3 -- ssa form updating improvements


Hello,

> On Tue, 15 Jun 2004 05:04:53 +0200, Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote:
> 
> >> > this patch adds a possibility to handle ssa form updating without need
> >> > to rewrite variables out of ssa form.  The idea is to allow to violate
> >> > the invariants of the ssa form temporarily and let a single ssa name
> >> > have several definitions.  A call to rewrite_ssa_into_ssa (running
> >> > standard ssa creation algorithm just over those ssa names) then
> >> > "repairs" the ssa form.
> >> > 
> >> This description doesn't look like a good idea.
> >
> > do you have a better one?  The only other way I see is incremental
> > updating, which would be harder to both implement and use.
> 
> Why would it be harder to use?

You need to apply it statement by statement.  New phi nodes are created
and ssa names renamed while you are still working with them.  You also
end up possibly renaming one name several times for each of its
definitions, which is not somehow terribly good for performance.

rewrite_ssa_into_ssa just puts the work together, making this all happen
at once when you need it.  In fact the standard incremental algorithm
presented by Kenneth does about the same amount of work (except for
scanning the body of the function for definitions, which could be
avoided with some care), so there also should be no major performance
reasons against using it.

> Kenny's keynote mentioned a function to
> just insert a new definition, which we have yet to implement, but seems
> like a very useful abstraction.  Would that serve your needs?
> 
> > What we do now is that we rewrite x out of ssa form, copy the header and
> > rewrite it back to ssa.  The drawbacks are that we lose aliasing
> > information and that we are inserting unnecessary assignments on places
> > completely unrelated to the loop.
> >
> > With the patch, we just copy the header,
> 
> This sounds very much like the situation with jump forwarding, which was
> discussed at the summit.

yes, exactly.  A functionality similar to rewrite_ssa_into_ssa is
neccesary to implement it as well.

Zdenek


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