arielf@taux01.nsc.com (Ariel Faigon) (12/14/89)
In a recent article, Liam Quin <lee@sq.sq.com> wrote: | Subject: Re: dynamic optimization -- summary | I asked whether there were any compilers (esp. on Unix) which took into | account statistics gathered from profiling runs when optimising programs. National Semiconductor's GNX family of compilers, Version 4.0, does it: Version 4.0 is scheduled for customer-release on February but we've already used it extensively for about a year now, in house. The technique was presented in IEEE ICCD (International Conference on Computer Design) 1988, By Chaim Bendelac & Gadi Erlich. The title of the presentation was: "CTP - A family of Optimizing Compilers for the NS32532 Microprocessor" --- Computer society order no. 872 Library of congress no. 88-82095 IEEE catalog no. 88CH2643-5 ISBN 0-8186-0872-2 --- The following is an excerpt from the manual; The Profiling-information can be used for automatic optimization. i.e. the GNX optimizer can utilize it in order to perform better optimizations like register-allocation and branch-prediction without user intervention. Each basic-block is assigned a value called 'exec_odds' (for execution-odds) to estimate the odds that this basic-block will be executed relatively to other basic-blocks. In the default-mode operation of the optimizer, 'exec_odds' is estimated by few heuristics (e.g. an inner loop is given more odds than an external one, each 'case' in a 'switch' statement is given the same odds etc.). When a special optimization option is used (and a profiling-information file exists from previous executions and some sanity checks verify that it is indeed of the same program that was previously compiled for profile-feedback), the 'exec_odds' values are calculated from that information. The sad news is that except in very rare cases, or some contrived ones, (e.g. a program that its inner loop is almost never executed), the automatic profile-feedback adds near to nothing to the optimizations that are normally performed by the optimizer (according to the heuristics). Yet, it may be that one wants to tune his program for very specific conditions (e.g. a very specific set of inputs which one foresees to be the most frequent in some environment) - then, this technique may prove worthwhile. And to the good news: We use the same profile-information for conventional profiling by marking source-lines with their respective number-of-executions. This, proved to be very helpful in studying runtime behavior of programs especially for white-box testing: detecting areas of low coverage (e.g. basic-blocks -> lines that are seldom/never executed). --- Ariel Faigon, CTP group, NSTA National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Hertzlia 46104, Israel Tel. (972)52-522312 arielf%taux01@nsc.com @{hplabs,pyramid,sun,decwrl} 34 48 E / 32 10 N -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue. Please send responses to the author of the message, not the poster.
alex@husc6.harvard.edu (Alex Zatsman) (12/18/89)
Here in Software Options we've built a so called CGBC back end (CGBC
stands for Code Generation By Coagulation). The technique was
originally developed by Mike Karr in his Ph.D. thesis. (see his
article in 1984 Proceedings of the SIGPLAN Symposium on Compiler
Construction). The back end expected as an input a flow graph with
frequencies for each arc.
Being only a prototype, the back end did not use any of the classical
optimization like strength reduction and loop invariants. Nevertheless
the code it produced was no worse and usually better than optimizing C
compilers for Unix (we compared it with Sun and Ultrix C compilers).
It should work much better than that once we have standard
optimization parts added to it, which is expected to be during next
year.
Alex Zatsman.
Software Options, Inc.
22 Hilliard St.
Cambridge MA, 02138
(617) 497-5054
--
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue.
Please send responses to the author of the message, not the poster.