NET-RELAY.ARPA>@brl-smoke.ARPA (10/09/86)
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. Thanks, Scott "In an evolving man-machine system, the man will get dumber faster than the machine gets smarter."
m5@bobkat.UUCP (Mr Mike McNally) (10/13/86)
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. > > Thanks, Scott > >"In an evolving man-machine system, the man will get dumber faster than >the machine gets smarter." A long time ago a professor told me about a compiler that somebody had written for a WCS lsi-11 (I think it was an 11/05). The compiler would use profiling information to decide which chunks of generated code needed to be compressed into a single, newly (and automatically) microcoded instruction. I always thought that this was nifty, although it seemed to me that upgrading to a faster processor would have been simpler :-) 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. -- **** **** **** At Digital Lynx, we're almost in Garland, but not quite **** **** **** Mike McNally Digital Lynx Inc. Software (not hardware) Person Dallas TX 75243 uucp: ...convex!ctvax!bobkat!m5 (214) 238-7474
mash@mips.UUCP (10/25/86)
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: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086