Re: When to do inline expansion

zstern@adobe.com (Zalman Stern)
Mon, 20 Sep 1993 21:03:42 GMT

          From comp.compilers

Related articles
When to do inline expansion jhall@whale.WPI.EDU (1993-09-14)
Re: When to do inline expansion zstern@adobe.com (1993-09-20)
Re: When to do inline expansion salomon@silver.cs.umanitoba.ca (1993-09-20)
Re: When to do inline expansion davidm@questor.rational.com (1993-09-20)
Re: When to do inline expansion jfc@athena.mit.edu (1993-09-21)
Re: When to do inline expansion jgmorris+@cs.cmu.edu (1993-09-21)
Re: When to do inline expansion jdean@bergen.cs.washington.edu (1993-09-21)
Re: When to do inline expansion salomon@silver.cs.umanitoba.ca (1993-09-22)
[4 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: zstern@adobe.com (Zalman Stern)
Keywords: optimize
Organization: Adobe Systems Incorporated
References: 93-09-063
Date: Mon, 20 Sep 1993 21:03:42 GMT

John Clinton Hall writes
> How long should a function be (in number of statements) for it to be a
> reasonable speed optimization to perform inline expansion? (For
> simplicity, let's assume that the function is only called once
> throughout the code, and the source language is C.) Obviously, a
> function with 100 statements should not be expanded; however, a
> function with only 1 statement should be expanded inline.


If it is called precisely once in the program, the function should be
inlined no matter what. (Assuming full optimization is requested.) Better
C compilers will do this for static functions within a file. (MIPS' C
compiler, IBM's xlc, and the GNU C compiler for example.)


> My guess is that executing 3 to 5 statements would equal the time it
> would normally take to set up the call, perform the call, and clean up
> after the call. Comments?


It depends a lot on your goals and compiler technology. If you're shooting
for top performance on scientific codes with a trace scheduling compiler,
you will want to inline anything possible (including 100 line functions).
If you're compiling a personal computer application, you will shun
inlining for most of the code unless it makes a function smaller. (This
occurs a lot with C++. E.g. when inline functions are used as accessor
methods on an object.)


I'd hesitate to draw the complexity criterion strictly at the statement
level though. 100 repetitions of "a = 0;" is pretty easy to inline. Some
systems (notably MIPS ucode) do inlining with an intermediate
representation of the code. This gives many more opportunities to decide
if the code can be profitably inlined. (As well as allowing inlining of
library routines.)
--
Zalman Stern zalman@adobe.com (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
--


Post a followup to this message

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