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

[Andrew MacLeod <amacleod at redhat dot com>]

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.

> > 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 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.

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.
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
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.
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.

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? :-)

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.

Andrew