Re: -fobey-inline (was Re: gcc and inlining)

[Andreas Schwab <schwab at suse dot de>]

dewar at gnat dot com (Robert Dewar) writes:

|> Now the compiler should react to this by actually doing the inlining if
|> indeed doing so can reasonbly be expected to improve execution time. But
|> there are a number of reasons why this may not be the case, often very
|> target dependent. Some examples:
|> 
|>   1. Increasing code space can increase instruction cache pressure, which
|>      is often a key element in execution efficiency.
|> 
|>   2. In some architectures, the call can help improve efficiency. For
|>      example, on the IBM 360, code has to be based, calling a function
|>      automatically bases the code, avoiding the need for allocating an
|>      extra base register and mucking with it.
|> 
|>   3. On some machines calls are particularly fast. For example, on the
|>      INMOS transputer, a call is remarkably fast, often close to free.
|> 
|>   4. A call is an unconditional jump, so is a simple return. On an
|>      architecture with good branch prediction and plenty of ILP it
|>      may well be the case that the call is operationally close to free

On the other hand, inlining a function can create great opportunities for
constant folding.  This is the point where gcc is currently very weak
because it bases its heuristics on the unfolded size of the inline
function.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab at suse dot de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."