Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.misc
Subject: Re: 'register' variables and other goodies (was Re: Common subexpression optimization)
Message-ID: <1624@aber-cs.UUCP>
Date: 9 Feb 90 19:46:41 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 53

In article <14226@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:

	[ an argumetn based on the assumption that commonly available
	compilers are very good at discoverin which variables
	are frequently used, and similar interesting things ]

UNFORTUNATELY, this assumption is unproven. Commonly available
compilers are not able to do this. What happens is that
virtually every compiler out there optimizes based on *static*
frequency of usage, and even this is irrelevant on many modern
machines that have more registers than most programs can use.

Compilers that can do a good job should either use heuristics,
or profile feedback, and are exceedingly rare. In both cases
the compiler becomes more complex (becomes it has to analyze
control and data flows as a preliminary -- it is this that makes
the compiler more complex, not the optimization per se). I think
that the programmer, *by design* (aided by heuristics and
profiling, yes) should know what is going on, and tell the
compiler instead.

In any case, whether compilers can or could do this analysis is
a different issue from whether the programmer *should* document
the performance assumptions made in a piece of program, and
whether the compiler should ignore this.

I reckon the programmer should, because I reckon that programs
ought to be as precise descriptions as possible, both as to
semantics and as to pragmatics.

The issue is then whether the reader of a program be it either
human or program should not be required to second guess the
author.

Once this is demonstrated undesirable, the issue of whether
compilers should do this, taking into account the extra
complexity and ensuing unreliability of getting a much more
sophisticated compiler, and the effectiveness of doing so.

Any technology should be examined as to it cost, not just as to
its benefit. Are aggressive optimizers so effective that the
added cost in compiler complexity and reliability, in encouraging
more sloppily written programs, in resource usage, is worth it?

A completely seaprate issue is instead that of having a
'programmer assistant' that aids the programmer with writing
source code, e.g. in doing program transformations; as to this
I am in favour, as long as this is not made part of a code
generator.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk