Related articles |
---|
SPARC code generation references ressler@cs.cornell.edu (1991-05-24) |
Re: SPARC code generation references torek@elf.ee.lbl.gov (1991-05-26) |
Re: SPARC code generation references preston@ariel.rice.edu (1991-05-28) |
Re: SPARC code generation references pardo@june.cs.washington.edu (1991-05-28) |
Re: SPARC code generation references array!colin (1991-05-27) |
Newsgroups: | comp.compilers |
From: | array!colin (Colin Plumb) |
Keywords: | SPARC, optimize |
Organization: | Array Systems Computing, Inc., Toronto, Ontario, CANADA |
References: | 91-05-100 91-05-101 |
Date: | Mon, 27 May 1991 16:14:42 -0400 |
There's a more general technique that, at the expense of code space, is
faster most of the time. You compile one version of the code that assumes
it's wrapped in a save/restore. Then you start compiling, outside-in, a
version that does not use save-restore. Every time you find you need to use
save-restore, you insert it and branch to the corresponding location in the
wrapped version.
This copes with such annoying cases as
void bufferchars(const char *s)
{
register char c;
while (c = *s++) {
*buf++ = c;
if (buf >= buflim) {
flushbuf(buf, buflim-bufbase);
buf = bufbase;
}
}
}
If you have a string that fits in the buffer, no save/restores are generated;
but if the string is many times larger than the buffer, you still only get
one save/restore.
I have glossed over many issues, mostly in that word "corresponding", as if
the optimal code didn't depend on how many registers you have free. But the
idea is there - postpone the save as long as possible, then do it and use an
alternate code sequence.
(Of course, do dead-code elimination, and move code around to turn jumps into
fallthroughs.)
--
-Colin
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.