Re: [reload] never-used stack slots?

[Jim Wilson <wilson at specifixinc dot com>]

Cyrille Chepelov wrote:
> 	0. Shouldn't %edx (call-clobbered) be preferred over %ebx? (nitpick)

%edx is required because the value lives across a call.  Granted we 
could have done better if it had been scheduled differently, but there 
is a difficult trade off here.  If we schedule before register 
allocation, we increase register pressure which tends to result in worse 
code.  If we schedule after register allocation, then we can't change 
the register assignments.  Currently, we only schedule after register 
allocation.

> 	1. There is one stack slot allocated, which is never used. The two
> instructions I've annotated above are thus useless.

It isn't safe to make assumptions about what happened here.  We need to 
know exactly why the extra stack slot got allocated.  There are many 
things that could have gone wrong here, and it isn't necessarily 
reload's fault.

Trying to eliminate a slot after reload has run, and adjust offsets will 
be extremely difficult.  I am skeptical that it can be done.  There are 
many machine dependent ways that addresses might get modified while 
reload runs, and you will need to be able to recognize them all and fix 
them all, and perhaps perform alternative rewrites of addresses which 
may require more/different spills.

> 	2. Notwithstanding the fact that the "subl $4,%esp" is unnecessary,
> shouldn't it be replaced with a "pushl %whatever", to save space? I can

This may be an optimization that hasn't occured to us.  Impossible to say.

> I wonder if the following shouldn't be done, sometime before lreg or
> regmove, if the last BB includes a function call, and that call is not a
> tail call:
> 	The last BB is split after the last call, into BB' and BB".
> Everything from BB' that can be moved down to BB" is moved (likely every insn from
> BB' that is not depended upon by the arguments to the last function call.

It isn't safe to make assumptions based on simple testcases.  In a 
larger function, we will need registers saved across the call anyways, 
so moving stuff after the call doesn't make things better.  It can 
actually make things worse, because it may increase register pressure 
after the call enough to make code worse.  It also reduces scheduling 
freedom before the call which may make code worse.  There are lots of 
ways this can make code worse, and a few ways that it can make code better.

In a small function where we wouldn't need to spill regs this might 
help, but determine when it might help may be hard.  Also, determining 
whether the function needs spills before we do register allocation may 
be hard.

What we would need is empirical data.  Try it, and see if it works, and 
if not, try to tune it.

> 	1. Are the powers that be aware of the issues here? (I suspect yes,
> 		but I haven't found evidence of that in bugzilla)

We are aware that gcc does not generate optimal code in all cases, 
because this is an NP complete problem, and gcc must run in polynomial 
time.  I can't say for sure whether any of the specific problems you 
mention are known.

> 	2. Are there bits of this e-mail worth recording into the bugzilla?

Probably.

> 	3. On the point of cleaning up the stack slot allocation in
> 		reload(), any comments on the feasability, and perhaps 
> 		implementation hints?

I think this will be hard, and there is no easy way to suggest how to 
implement it.

> 	4. On the point of splitting the last BB of a function if it
> 		contains a call, is this stupid, and if it's not, any 
> 		comments on the feasability and perhaps implementation 
> 		hints?

Try it, and see if it works.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com