Re: Code folding from JSR/RTS -> {Local}

carter@cs.wisc.edu (Gregory Carter) writes:
>[Optimize:
> (1) local vars -> global vars
> (2) replace subroutine calls with the subroutine code
> (3) minimize stack frame usage]


On many machines (RISC machines in particular), accesing global memory is
no faster than accessing local variables. The cost of stack pointer
update is, of course, larger than no update. For larger procedures the
cost is minimal. Smaller procedures can be inlined and/or values just
kept in registers. It would be possible to do flow analysis and do one
stack pointer update for several nested calls; I know of no such work but
it's conceptually easy. In general, the biggest win is from making
effective use of registers, and if you can't fit it all in 32 registers,
you're already doing enough work tht the cost of a stack pointer update is
small.


As John Levine points out, some compilers support function inlining. The
code often gets larger and on machines with caches, may get slower.


A number of compilers attempt to minimize stack frame usage. On CISCs
such as the VAX and i386, stack usage is a part of the calling convention
defined by most compilers. On RISCs, the compilers can often optimize
leaf procedures enough to eliminate all stack references. The SPARC
compilers can also optimize away leaf procedure register window saves and
restores (register windows implicitly consume stack space).


So the answers are


(1) It's not usually a big win
(2) See GCC and other production-quality compilers
(3) See GCC and other production-quality compilers




As an aside, several C compilers I've looked at take code of the form


foo(){ {int a[SZ]; ...} {int a[SZ]; ...} }


and allocate two `SZ'-sized slots on the stack. This doesn't cause any
extra stack pointer updates but does reduce the localit of reference.


;-D on ( Code twisting ) Pardo
--

Return to the comp.compilers page.
Search the comp.compilers archives again.