Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!sri-spam!nike!ucbcad!ucbvax!decvax!decwrl!labrea!glacier!mips!mash From: mash@mips.UUCP Newsgroups: net.lang.c Subject: Re: Optimizing C Compiler Sought Message-ID: <731@mips.UUCP> Date: Sat, 25-Oct-86 01:32:10 EST Article-I.D.: mips.731 Posted: Sat Oct 25 01:32:10 1986 Date-Received: Sun, 26-Oct-86 01:33:58 EST References: <4467@brl-smoke.ARPA> <160@bobkat.UUCP> Reply-To: mash@mips.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 38 In article <160@bobkat.UUCP> m5@bobkat.UUCP (Mr Mike McNally) writes: >In article <4467@brl-smoke.ARPA> NET-RELAY.ARPA>@brl-smoke.ARPA writes: >>Does anyone know of a C compiler that will use its own profiling output >>to generate faster runtime code? I've long thought that a compiler that >>didn't accept data about the runtime behavior of a program shouldn't >>call itself a execution-time optimizing compiler - space maybe but not time. > > >In the case of optimizing C, there are various well-discussed semantic >characteristics of the language which prevent all but the most local >optimizations (I personally have never been convinced that this is >always a ``feature''). Even if it were possible to do local or global >common subexpression elimination, loop unravelling, induction variable >elimination, etc., I think that allowing the compiler to optimize >anything it can will result in good code. Useful profile information >might be somewhat difficult to generate, given a program with several >possible flow characteristics and large possible input sets. The only >use of such information would be to make space/time tradeoff decisions, >and these probably are more easily done through some sort of ``pragma'' >construct. 1) It certainly is possible to do the optimizations mentioned, although they don't do you as much good in C as they do for FORTRAN or PASCAL. 2) Profiling feedback is usable. The MIPSco compiler system has a [not released, not counted in benchmarks, optional, etc] compiler phase that can take profiling feedback files, then use the information for selective inlining of procedures. The feedback files get down to the basic block, i.e., effective statment-by-statement counting. "Selective inlining" means that you grab procedures inline only where they're called frequently. Besides eliminating function calls, this lets a serious optimizer move newly-exposed-constant-subexpressions out of loops, and eliminate newly-visible dead code. [Note that many arguments to functions are constants, tests upon which can be eliminated at compile time.] -- -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