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

[Jan Hubicka <jh at suse dot cz>]

> On Wed, 2003-11-05 at 04:20, Jan Hubicka wrote:
> > > On Tue, 2003-11-04 at 16:17, law@redhat.com wrote:
> > > > In message <1067979853.7039.50.camel@p4>, Andrew MacLeod writes:
> 
> > 
> > Please lets try to move out of running
> > remove_useless_stmts_and_vars_cond.  In the case we want to preserve CFG
> > during RTL expansion, we can not do it.
> > 
> 
> remove_useless_stmts_and_vars_cond could keep the cfg updated if it
> wanted to. It didnt before becuase it was thrown away immediately
> aftewards, so what was the point. Now perhaps there is a point.

We can do it that way, but the function should be mostly NOOP now.
cleanup_cfg+dead code removal should've caught all cases previously.
> 
> > > for a single stmt in the target of the COND_EXPR arm now, if that block
> > > contains nothing but a GOTO and a single stmt in the *next* block, then
> > > it has the same situation.
> > 
> > I think it makes sense add flag to thread_jumps to know whether it is in
> > SSA or not SSA form.  In SSA form we can disable redirections where we
> > don't know how to update SSA graph and we can run it once after
> > expanding out of SSA afterwards.
> > 
> > On the other hand, I was thinking that in longer run, we can probably do
> > out-of-SSA as part of RTL expansion.  In highlevel point of view, this
> > is easy.  You can teach expand_expr to deal with SSA_NAME tree node and
> > we can insert RTL copy statements on the edges during expansion process
> > and call commit_edge_insertions afterwards.  That way we save number of
> > temporaries produced.
> 
> Thats not going to change the number of temporaries. None of the copies
> inserted create new temporaries unless there is a cycle, and you cant
> avoid creating one in that case.

The point is that we *want* to create temporary registers so unless
there is good reason to do so, we don't want single register to be set
two times.  That confuses RTL.

In the case we teach out-of-SSA code to do so, we end up with many
temporaries.
> 
> 
> > The motivation is that current sheme of sharing temporaries for
> > syntactic tables and attempts to re-use same variables as much as
> > possible on out-of-ssa pass (that I believe has only advantage of saving
> > memory needed by VAR_DECL/IDENTIFIER nodes) results in unnecesary RTL
> > registers reuse that in turn badly confuse any local optimizer we do
> > have turning temporaries global.
> 
> I have some ongoing work in SSA->normal which remove all temporaries
> which are used only once. This reduces the number of temporaries
> significantly. In many cases, the object footprint generated is even 10%
> smaller.

You mean that it will re-insert the expression back into the form
(basically undoing the gimplification?)
Yes, that would help too.
> 
> If live ranges are disjoint for the same variable, we ought to be using
> Vlad's code which splits disjoint live range on registers. He has it,
> but hasnt submitted it for mainline because it wasn't doing enough good.

webizer split's the disjoint live ranges too.  That is what I did.
It is, however, unnecesary to do so since we can do it for free while
going out of SSA.
Of course in case we end up with SSA, I will just propose patch to run
limited webizer when optimizing early in the queue.

> It ought to be considered for inclusion here to resolve any unrelated
> register dependancies
> 
> So are you proposing that SSA->normal map SSA version variables directly
> to registers? instead of back to their root variable like they do now?
> That would preclude anything being done on trees after SSA. Not that
> there is anything right now, but thats not to say there won't be
> something later. 
> 
> So you would assign every SSA_NAME variable a unique register, and
> generate rtl directly?  You would still have to attempt to coalesce any

Kind of.  The out-of-SSA pass works by first deciding how to match
SSA_NAMES to variables and then do the rewriting.
We can do the second part easilly without rewriting during expansion
time and in addition we can manage thinks in a way so we don't need to
invent new DECL_NODEs for temporaries saving some overhead.
Not sure.
> SSA_NAME variable in a PHI node first, otherwise you are going to get a
> zillion register copies. So I'd at least try to keep that part of the
> SSA->normal pass seperate, and that is actually a goodly portion of what
> SSA->Normal does.. Build the interference graph and coalesce SSA
> variable in PHI nodes. Of course, it also does it for SSA variables not
> in PHI nodes, but the way temporaries are generated by the gimnplifier,
> most of the intermediate temporaries are unique, and we'll be getting
> rid of most of those in SSA->normal shortly anyway. hopefully profitably
> :-)
> 
> I'll have to think about it some more, but the more I think about it,
> the less sure it will buy us much.  We can certainly modify the
> expanders to understand what an SSA_NAME is, and generate a register for
> those when they are seen. I can see some merit in that, and then have
> SSA->normal only attempt to coalesce variables which appear in PHI nodes
> to help eliminate copies... and insert any required copies using the SSA
> versioned variable instead of the root variable like we do now. At some
> level, that is the same as what we do now, except we dont greate new
> VAR_DECLs, just SSA_NAMES... so its still kind of the same.

We can insert the copies in RTL form already, so we save some extra
trees.
> remove_useless_stmts_and_vars() removes any VAR_DECLS which we've
> indicated aren't used in the propram, so really, eliminating the temps
> is all we're talking about doing this for.

Yes, it saves us the tree nodes for temps, inserted copies and one walk
of the function body.  That is it.
> 
> We'd have to be careful about address taken and that sort of thing
> happens... there are places where an ssa versioned variable must be in
> memory, so I guess those ones we would still have to coalesce into a
> variable where required, but thats certainly doable.
> 
> I dont know the expanders very well, but presumably handling just
> SSA_NAME wouldn't be too difficult.. (would it? :-)

It should be quite easy.
> 
> Anyway, we'll see what kind of results I get with the temporary
> elimination in SSA->normal that Im testing now. Its not a lot of code,
> and is performed during the SSA->normal rewrite phase.

OK, lets wait with this until the code is more stabilized and
benchmarked.  THen we will likely know how much burden the de-ssa pass
is.

Honza
> 
> Andrew
>