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

[Andreas Schwab <schwab at suse dot de>]

Steven Bosscher <s dot bosscher at student dot tudelft dot nl> writes:

|> Op ma 17-03-2003, om 11:47 schreef Andreas Schwab:
|> > Steven Bosscher <s dot bosscher at student dot tudelft dot nl> writes:
|> > 
|> > |> Look again at kernel programming, or even better, at Alexandre's example
|> > |> of a dynamic loader.  And those are just the very extreme examples, but
|> > |> for some user code it might well be that the user sometimes has very
|> > |> very good reasons to inline something when the compiler would not
|> > |> normally consider that function for inlining.
|> > 
|> > IMHO these are the places where __attribute__((always_inline)) is the
|> > right fix.  When the compiler has become smart enough the case where this
|> > is still needed should become rare.
|> 
|> Hmm, I tried to make a point that there is no such thing as "smart
|> enough", only "smart enough for where it's tuned to be smart".  Really,
|> I'd love to see really a smart inlining decision algorithm, but in the
|> end a compiler will always just be guessing.

When inlining is required for reason of semantics (eg. dynamic linker
startup) you are outside the scope of the standard and always_inline is
IMHO an appropriate answer.

|> Now I'd love to be proven wrong.  How would you want to make the
|> compiler smarter, what heuristics are you thinking of here?

Time moves forward, and better algorithms will be found, just like today's
register allocators are good enough to be able to ignore the register
keyword (although some people still think they know better).

|> Also, you ignore the point that the final decision should be left with
|> the user.  Apparently you disagree with that?

always_inline gives you the control.

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."