Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg
From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.lang.misc
Subject: Re: 'register' variables and other goodies (was Re: Common subexpression optimization)
Message-ID: <PCG.90Feb13161349@rupert.cs.aber.ac.uk>
Date: 13 Feb 90 16:13:49 GMT
References: <1624@aber-cs.UUCP>
	<1990Feb12.172948.17784@jarvis.csri.toronto.edu>
Sender: pcg@aber-cs.UUCP
Organization: Coleg Prifysgol Cymru
Lines: 69
In-reply-to: cks@white.toronto.edu's message of 12 Feb 90 22:29:48 GMT

In article <1990Feb12.172948.17784@jarvis.csri.toronto.edu> cks@white.toronto.edu (Chris Siebenmann) writes:

    Profiling feedback compilers are becoming more and more common and at
   least one set are fairly widely used: the MIPSco compilers.

Sure the MIPSco people would love their compilers to be widely used...
Sure DEC is contributing powerfully... :-) :-).

    I agree that programmers should have some way of manually telling the
   compiler about usage frequency.

Definitely yes! Even if the compiler uses heuristics or profiling,
the programmer may still know better in certain cases.

   However, given that we're already assuming a profiler at work, and
   the usual quality of commercial programmers, I think it's foolish
   not to let the compiler/linker read the profiling results directly.

   When something is simple and mechanical, why not let the computer
   do the drudge work?

I tend to agree in principle. In practice, things are less clear
cut.  To make use of profling and heuristic information, the
compiler has to run complex analysis and optimizing modules. This
is *bad*. The beauty of things like 'register' is that they are
absolutely safe and effective, without any analysis whatsoever.

   I wonder how many programmers even bother running a profiler on their
   programs? I suspect not many.

Very few. Actally, in most cases, profiling requires recompilation,
and this is often not very attractive, and in any case very few
programmers would understand the profile.

I think that rather than sticking complex, often unreliable and
ineffective optimizers in the bowels of code generators, the
following topics should be explored:

1) ways to make languages safer without requiring complex analysis;

2) ways to describe the semantics and pragmatics of a program, both
   to human and programmatic readers;

3) ways to make it easier to profile for time, e.g. for a coarse first
   run use statistical PC sampling, without recompilation, and then
   using flow graph based tecniques;

4) ways to make it possible to profile for space, e.g. for a coarse first
   run use statistical page reference sampling, without recompilation, then
   using flow graph based techniques, e.g. in malloc() or equivalents;

5) programmer's assistants that do a thorough analysis of the source code;

6) programmer's assistants that help make transformations of the source code;

7) training better programmers (oh well, let's dream...).

I am aware of some work in the literature about these points
(Alpeh, Euclid, lint, ....), but it is pitifully small compared
to the vast effort expended on what by comparison is an unsafe,
inefficient shortcut, "optimizers", not to mention recent
standard efforts that have worsened problems (volatile!).

If you look at things cynically, "optimizers" are a shortcut most
effective only on benchmarks, and these sell machines...
--
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