Summary of "Languages that give 'hints' to the compiler"

Joe Hummel <jhummel@cy4.ICS.UCI.EDU>
Wed, 3 Aug 1994 00:33:44 GMT

          From comp.compilers

Related articles
Summary of "Languages that give 'hints' to the compiler" jhummel@cy4.ICS.UCI.EDU (Joe Hummel) (1994-08-03)
Re: Summary of "Languages that give 'hints' to the compiler" (1994-08-03)
Re: Summary of "Languages that give 'hints' to the compiler" jhummel@cy4.ICS.UCI.EDU (Joe Hummel) (1994-08-04)
Re: Summary of "Languages that give 'hints' to the compiler" (1994-08-08)
Re: Summary of "Languages that give 'hints' to the compiler" (1994-08-13)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Joe Hummel <jhummel@cy4.ICS.UCI.EDU>
Keywords: optimize, summary
Organization: UC Irvine, Department of ICS
Date: Wed, 3 Aug 1994 00:33:44 GMT
Status: RO

Hi all. About two weeks ago I posted a "call for information" about
programmer-directed optimization -- where the programmer supplies info to
the compiler by way of assertions or pragmas. I was curious about what
other approaches people might be familiar with, what languages support
this kind of thing, etc.

Here's a summary of the messages I received (along with the messages posted
to comp.compilers directly). To save bandwidth I'll just summarize the
overall content of the messages; if anyone wants more detail on a particular
subject, feel free to send me email ( and I'll supply
any additional info that I have.

BTW, I'm still interested in evidence/intuition about how often programmers
use this kind of approach. Given the moderator and Josh Fisher's note about
Fortran's Frequency statement (that no one realized it had been implemented
backwards), one wonders if people use directives or pragmas for optimization
at all.

And thanks again to all who responded (about 20 people altogether).

    - joe


SUMMARY: a number of languages provide a number of different ways of
providing additional info to the compiler (in no particular order):

    - FORTRAN's Frequency statement, was dropped.
    - DEC's Decal language for PDP-1 allowed programmer to specify code to
        produce for a block of statements, was dropped since hard to debug
        the result.
    - C's register, inline, const, static, and volatile keywords all supply
        opt info to the compiler.
    - NCEG's proposed RESTRICT keyword, which states that a restricted pointer
        provides unique access to a memory location (NCEG == Numerical C
        Extensions Group).

    - LISP:
            -- proliferation of operators (e.g. times, times2, ...) can be seen
                  as a form of programmer-directed opt.
            -- common lisp's DECLARE and PROCLAIM statements, which specify
                  function specific and global info, respectively. For example,
                  (declare x fixnum). Very flexible, used to choose compilers,
                  optimization vs safety level, types, etc.
    - Prolog: some allow you to specify whether params are in, out, or in/out.

    - Bulldog VLIW compiler allowed programmer to communicate invariants to
        the compiler via assertions.
    - Dylan's "unless a then b" construct could imply that b is the more likely
        case (at least the compiler could assume this, and the programmer could
        be told to expect this).
    - OPAL allows the programmer to specify algebraic properties of functions,
        which the compiler can use for optimization purposes.

    - languages can allow the programmer to override an implementation with
        their own, thereby optimizing for the case expected by the programmer;
        e.g. Smalltalk and Self allow this at run-time, and Lisp as well (?).

    - a Ph.D. thesis of interest: "Exploiting Specifications to Improve
        Program Performance,", ftp to, get the file

Note that this last item, allowing an implementation to be public and
overridden, was the topic of a panel discussion at this year's OOPSLA ("black
box versus white box"). For performance reasons, people are beginning to
consider white box designs.

    A number of people also pointed out that profiling can be used to feed info
back into the compiler for optimization purposes (branch prediction, code
placement, inlining, type prediction in OOPLs, etc.). Since this method is
automatic (from the compiler's viewpoint), most people also seemed to feel
that this approach is more reliable and thus preferable.

    One person had a nice thought I'd like to quote: "... any feature of a
compiler that makes use of a programmer hint will quickly evolve into a
feature which gets the info from a more reliable source." Hence the use of
interprocedural analysis, profiling-feedback, etc. On the other hand, note
that interprocedural analysis can be very expensive (e.g. when pointers are
involved), and it doesn't help when compiling libraries. Profiling-feedback
works well, but how limited is its domain? For example, can the compiler
decide what data distribution to use from static analysis and profiling
information? Perhaps, but the HPF people have chosen to add statements to
FORTRAN to allow the programmer to supply this kind of information.

    The big gotcha of course: what if the programmer supplies info, and he/she
is wrong? How do you debug code that the compiler has optimized behind
your back? Run-time checks can be used in some cases, but in general?

Joe Hummel
ICS Graduate Student, UC Irvine

Post a followup to this message

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