Stack Reorganization Patch

[Zack Weinberg]

"Naveen Sharma, Noida" <naveens@noida.hcltech.com> writes:

>> (2) You need testing on more architectures.  If you turn on the
>>     optimization unconditionally, you can test against most
>>     interesting architectures by using cross compilers to simulator
>>     targets.  There are detailed instructions for this on the GCC
>>     website.  Pick five popular architectures, verify that there are
>>     no regressions, and do a code size comparison for each one.
>>     (Speed measurements are unlikely to be meaningful for a
>>     simulator.)
>
> I can test it using simulators but it is slightly difficult for me
> because of resources required.  I will need help from people who
> have expertise in those architectures.

That's fair.  I have scripting to do simulator runs on lots of target
architectures; if you send me your next revision I can do this for you.

> Please suggest architectures that might benefit from this
> optimization (Possibly HPPA, ARM-THUMB, and possibly alpha).

Honestly, I expect it to be a win everywhere.  I'm not aware of any
architectures that don't have short and long displacements, except
possibly ia64.  The difference may be hiding in the assembler - eg.
ia32 reg+imm indexing is written the same way whether it's an 8-bit or
32-bit offset.  Also, the patch should enable the generic RTL
optimizers to do a better job.

I'd do arm, alpha, mips, powerpc, i386.  But that's because those are
the architectures I'm most familiar with.  Some of our other oddball
embedded chips might also be good choices.

>> (5) Must you call stack_reorg() from the middle of reload?  Can't you
>>     do it immediately before or after?
>
> stack_reorg () will have little effect before reload because most of
> the stack allocations are from within reload. And replacing stack
> pseudos with their normal form after reload () turns out to be
> complicated (validation of changed rtx's becomes part of of
> stack-reorg, a task that reload is already doing).  So calling
> stack_reorg () from within reload turns out out be 1) simpler and 2)
> reload's code for generating valid rtl can be used.

Okay.  Objection withdrawn.

zw