Re: Caller allocates space for callee-save registers

pardo@cs.washington.edu (David Keppel) writes:
>Code where parameter passing is a substantial part of the total cost is,
>in fact, common, but you really need a stronger case than ``it's not
>unheard of'' before it's generally worth optimizing.


Actually, my point is that it isn't clear that it's worth doing much at
the software level if the hardware can take up the slack. I got into this
discussion by pointing out that you can't always expect modern code to do
a good job using registers. What _I_ end up doing is letting the code do a
poor job using registers, but making sure that there are lots of them.




>Second, reducing call overhead from parameter passing is a day-to-day
>optimiation, done e.g., through procedure inlining.
..
>If you stand on your head and squint just right, I believe the dynamic
>linking optimization descsribed in [92-06-030] wins partly because it's
>doing dynamic inlining.


Actually I like the idea of dynamic inlining, except that it looks utterly
useless in the case of dynamically loaded code into an interpreter,
because you will continually grow the interpreter if you can inline the
code in a useful way, but before you run into that problem, you have to
figure out where the thing gets called in the _interpreted_ language, and
that code isn't necessarily "findable" since you might be replacing an
entry point which can be called both by internal parts of the interpreter
and as a result of the interpreted language. It's also a worry that if you
can inline stuff into code you don't know, that you might inflate loops so
that they don't fit in come cache any more, or introduce unfortunate page
faults, just like when you inline code in the usual way, except that you
don't have much hope, beyond guessing, of figuring out what's happening to
you.


I think it's easier just to get a boatload of registers in case you can't
schedule them well.


Later,
Andrew Mullhaupt
--

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