Re: [tree-ssa] New regressions as of 2003-11-04

[Andrew MacLeod <amacleod at redhat dot com>]

On Wed, 2003-11-05 at 09:09, Diego Novillo wrote:
> On Tue, 2003-11-04 at 21:50, Andrew MacLeod wrote:
> > On Tue, 2003-11-04 at 20:52, Diego Novillo wrote:
> > > On Tue, 2003-11-04 at 16:51, law@redhat.com wrote:
> > > 
> > > > if (set != -1)
> > > >   goto lab1;
> > > > else
> > > >   goto lab2;
> > > > 
> > > > lab1:
> > > >   set = 0;
> > > >   goto lab3;
> > > > lab2:
> > > >   set = -1;
> > > > lab3:
> > > >   [ ... ]
> > > > 
> > > > Which looks precisely like what we've got now.
> > > > 
> > > Yes, but what I had in mind is to go out of SSA in DOM order.  Andrew
> > > was thinking of doing some post-processing in the out-of-ssa pass. 
> > > Maybe we could add this as well.
> > > 
> > > Andrew, does that sound too gross for the out-of-ssa pass?
> > 
> > What does going out of SSA in DOM order do?
> >
> It lets you keep track of equivalences like this one and avoid inserting
> unnecessary copies.
> 
I don't think that SSA->normal ought to understand equivilences at all.
You are trying to jimmy something that doesnt belong into it.
SSA->normal's job is to turn SSA_NAME's into real variables, resolving
PHI's along the way.   

Understanding what an expression is I dont think makes any sense, and
adds unnecessary complexity.


> >  SSA->normal doesnt klnow
> > anything about equivilences, and Im not too keen on teaching it anything
> > about them.
> > 
> *shrug*  I think it's cleaner if this was handled within the framework. 
> I'd like to avoid piling hacks on remove_useless_stmts_and_vars.  But
> I'll go with whatever works and is maintainable long term.
> 

I think teaching SSA->normal to understand equivilences is a *much*
bigger hack than having a seperate pass afterwards that does some
maintenance.

> > I dont understand why the existing routines wont work with a little
> > tweaking... The inforamtion is still identical, there just happens to be
> > a branch in between instead of the stmt hung off the COND_EXPR.  If the
> > existing stuff does destroy the CFG, perhaps we ought to do this part of
> > it before we destroy the CFG.....
> > 
> We actually want to preserve the CFG until RTL expansion time.  I
> believe Jan or Zdenek had plans for that.
> 

Yes, I beleive it was not needed after SSA->normal before, and so thats
why Jeff didnt bother to update the CFG in
remove_useless_stmts_and_vars(). Its probably easier to keep updated in
the lowered form... ?

Andrew