Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!world!iecc!compilers-sender
From: compilers-sender@iecc
Newsgroups: comp.compilers
Subject: Re: SPARC code generation references
Keywords: SPARC, optimize
Message-ID: <91-05-106@comp.compilers>
Date: 27 May 91 20:14:42 GMT
Article-I.D.: comp.91-05-106
References: <91-05-100@comp.compilers> <91-05-101@comp.compilers>
Sender: compilers-sender@iecc.cambridge.ma.us
Reply-To: array!colin (Colin Plumb)
Organization: Array Systems Computing, Inc., Toronto, Ontario, CANADA
Lines: 38
Approved: compilers@iecc.cambridge.ma.us

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

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.