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

[Andrew MacLeod <amacleod at redhat dot com>]

On Wed, 2003-11-05 at 10:35, Jan Hubicka wrote:

> 
> Webizer makes about 0.5% difference on mainline, over 1.5% difference on
> tree-SSA, so we obviously made this worse by unnecesary re-use.

My analysis of crafty indicated that the use of all these temporaries
causes a lot of uneccesary spilling by the register allocator, and we
were losing a lot of runtime because of that.

We'd load values from a couple of temps, discover we needed a register,
Spill one of the values we loaded from a temp, do something, then load
that value from spill... Doh! This was very common in arithmetic
operations incolving long longs. We'd end up with 7 or 8 instructions
because of silly spill code instead of the required 4 in many cases.


> > > You mean that it will re-insert the expression back into the form
> > > (basically undoing the gimplification?)
> > > Yes, that would help too.
> > 
> > Yes, the code coming out of SSA will no longer be GIMPLE.
> That is cool.  I guess it should bring RTL expansion mostly back to the
> shape :)
> > 

Thats the hope :-)

> > I think register allocation is the right place to be splitting disjoint
> > live ranges. I've worked on other compilers where the backend *tries* to
> 
> Not for GCC, as all the stupid local passes benefit from it greatly too.
> At the moment I do the splitting (webizer) after loop unrolling (because
> it introduces such a re-use) and trying to maintain the constraint of
> not inventing re-use up to reg-alloc.

:-). Well, at least its easy to do after the fact. 

I can't get use to use guys using the term "web", it means something far
more complex to me for some reason :-)

>
> You do expect sane compiler, not GCC :)

unfortunately, thats true :-) We're trying to make it more sane :-)


> > Wll, SSA->normal introduces few new VAR_DECL nodes. Only when 2 SSA
> > versions overlap do we get a new one, and its pretty goopd at producing
> > a minimal number of them. It will try to coalesce as many as possible
> 
> This is the problem.  We should introduce new VAR_DECLs when the live
> ranges does not overlap to get as many different pseudos as possible
> without introducing register copies to make RTL backend happy.
> 
> One of reasons why you idea to re-combine gimple nodes works is that you
> hide these re-used temporaries and we reinvent them during expansion in
> the way RTL expect.

yes, we get prettyt much the same benefit. the only time we don't is
when there is multiple uses of a temp, or a single use we dont merge for
some reason. Then we still have the var_decl.

Even after I do this stuff, it might still be helpful to translate
remaining SSA_NAME variables directly into rtl, I dont know yet.

> I would say it makes sense to wait month or two for the whole thing to
> somewhat settle down.  There are too many changes on the way to expect
> benchmark results to be usefull right now I would say.
> 

yep. I use the to find the spots where we have a significant difference
between us and mainline in order to identify what we are doing wrong and
fix it.

Stability has bene a big problem later. Once we get some of these large
pervasive things out of the way it ought to settle down.

Andrew