Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!mit-eddie!genrad!decvax!decwrl!pyramid!prls!mips!mash From: mash@mips.UUCP (John Mashey) Newsgroups: comp.lang.c Subject: Re: Porting PCC Message-ID: <474@winchester.UUCP> Date: Sun, 21-Jun-87 14:32:02 EDT Article-I.D.: winchest.474 Posted: Sun Jun 21 14:32:02 1987 Date-Received: Tue, 23-Jun-87 00:45:02 EDT References: <2082@dg_rtp.UUCP> <5975@brl-smoke.ARPA> <6604@ism780c.UUCP> <21214@sun.uucp> <801@omepd> <2684@hcr.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 51 In article <2684@hcr.UUCP> mike@hcr.UUCP (Mike Tilson) writes: >In a discussion of QCC and RCC, Steven McGeady (mcg@omepd.UUCP) writes: >> What V.3 *still* does not have, and would do the reputation of PCC-based >> compilers a world of good, is a (mostly) machine-independent >> intermediate code optimizer... > >You may be interested to know that exactly such a thing has already been >developed. An early version of HCR's "Portable Code Optimizer" (PCO) was >described in the Portland USENIX/85 proceedings.... >Adding optimization to PCC (and successors) has several advantages: You >don't change language semantics (a new optimizing compiler built from >the ground up invariably seems to have a slightly different definition >of C -- someday the ANSI standard may fix this, but not yet), existing >engineering is retained (e.g. code generator, local optimizer), and PCC >extensions such as "asm" can be retained (although functions using asm >aren't globally optimized). One goal of the project was to be able to >compile the UNIX kernel with PCO and still have it work, and this goal >was met. (By the way, as most of you know, global optimization doesn't >buy much on the kernel -- it has already been hand-tuned for years, and >real "hot spots" are written in hand-coded assembler.) All of this is indeed a reasonable compromise approach, and is probably the easiest way for many to get a better level of optimization. A few notes in defense of from-scratch optimizers: a) A complete language system amortizes the overhead of having an optimizer by using common components for multiple frontends. In some domains, it IS important to support C, FORTRAN, PASCAL, PL/I, ADA, etc, etc, in a coherent way. [This is not to say that the PCO approach can't be used, just that you can think of developing technology easier if you know you're going to use it broadly.] b) At least some optimizers do compile the kernel [we do, so do others]. c) In our case, we gain about 15% performance by adding the first level of global optimization, over some pretty good local optimization. That may not seem like much, but it is about the equivalent of an extra VAX 11/785 on our systems. (Actually, most of the current kernels aren't bad to optimize; the various namei incarnations are the worst, but also useful, since you DON'T want to recode them in assembler!) Mike is right in noting that you get less benefit for the kernel than for most user-level code. You do get some, and it is noticable when you use the systems. d) I am curious to know if PCO is used to optimize device drivers. Even common subexpression elimination can surprise you if you don't support volatile. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086