Re: Aggressive optimization

daveg@near.cs.caltech.edu (Dave Gillespie)
23 Oct 90 18:23:38

          From comp.compilers

Related articles
Re: Aggressive optimization brnstnd@kramden.acf.nyu.edu (1990-10-18)
Re: Aggressive optimization eerke@cs.kun.nl (1990-10-19)
Re: Aggressive optimization burley@world.std.com (1990-10-20)
Re: Aggressive optimization baxter@zola.ICS.UCI.EDU (Ira Baxter) (1990-10-23)
Re: Aggressive optimization daveg@near.cs.caltech.edu (1990-10-23)
| List of all articles for this month |

Newsgroups: comp.compilers
From: daveg@near.cs.caltech.edu (Dave Gillespie)
In-Reply-To: burley@world.std.com's message of 20 Oct 90 07:16:29 GMT
Keywords: optimize, design
Organization: California Institute of Technology
References: <1458@exodus.Eng.Sun.COM> <13405:Oct1800:22:5690@kramden.acf.nyu.edu> <2301@wn1.sci.kun.nl> <1990Oct18.223231.22315@esegue.segue.boston.ma.us> <BURLEY.90Oct20081629@world.std.com>
Date: 23 Oct 90 18:23:38

>>>>> On 20 Oct 90 07:16:29 GMT, burley@world.std.com (James C Burley) said:


> What I think is really needed is not only a compiler (here I refer to the
> total package of translating, including linking and debugging) that can
> recognize and deal with the kinds of optimizations Dan talks about, but that
> is easy to interact with, converse with, and to which the programmer can
> easily explain other constraints and point out other optimizations worth
> trying.


One way to start toward your grand plan would be to have the compiler output
a file of "I wish I had the following asserts/pragmas" notes correlated with
line numbers. A smart editor, maybe a major mode in GNU Emacs, could go back
and filter these into the original code in the form of comments. The user
would then know that, if he/she uncommented one of these pragmas (after
checking that it was safe to do so, of course), the optimizer would be able
to improve the code significantly.


Most of the things a good optimizer would like to know can be phrased as
assertions, or can probably be described in a suitable language of pragmas.
The advantage here is that these assertions are likely to remain meaningful
even as the code later evolves. If the compiler sees an assertion that no
longer makes any sense (say, because parsing it produces an error of some
kind) it can tell the editor to flag it for the programmer's attention.


It should also be possible to format these notes in a way that causes the
editor to treat them as invisible. (GNU Emacs has facilities for this right
now.) If the compiler puts up a "sure would be nice if X were nonnegative"
note and I determine that, in fact, X *won't* always be nonnegative, I'd like
to hide the note rather than deleting it so that it won't keep popping up
again. It's important to get rid of it *somehow* so that there won't be
pressure on the compiler not to generate as many notes as it can think of. I
only have to hide them once and forget about them. Some day if I need to
squeeze a certain routine some more I can go back and unhide its note to see
if any of them can be made to apply by massaging the rest of the program.


Other notes that I'd like to be able to give to a compiler are "please
optimize this function to death", "this `if' condition is rarely true", and
so on. The former note would, among other things, trigger the generation of
lots more "I wish" notes from the compiler.


-- Dave
--
Dave Gillespie
    256-80 Caltech Pasadena CA USA 91125
    daveg@csvax.cs.caltech.edu, ...!cit-vax!daveg
--


Post a followup to this message

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