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

[dewar at gnat dot com (Robert Dewar)]

> No, if the function is marked inline incorrectly the programmer should 
> discover it and remove the it himself. C is not a language there the 
> semantics mean: "I have no idea what I am doing, so please to whatever you 
> want with what I write".

I strongly disagree with this. In normal usage, inline simply means "I really
want calls to this to be as fast as possible, and if necessary sacrifice space
for speed". If a compiler knows that it is not significantly helpful, or possibly
that it is even unhelpful to inline, then it is silly to inline. Furthermore, this
does not correspond to a mistake in the C program, since it may be target dependent
whether inlining is significantly helpful (on machines with very small icaches,
inlining big functions very often results in slower performance).

I do think it is useful to have a switch which causes warnings to be generated
in cases where the compiler could not, or would not do the inlining, most helpfully
with an indication of why not.

Yes, as we all agree, there are cases where inline is NOT about speed but
but about functionality, and in such cases, the inlines should be specially
marked.

As for the quote about C, I think it's a bit off target. These days with modern
processors, C like any other high level language is very much a language where
the semantics mean "I have no idea what machine language should be generated
for this, I expect you to figure out the fastest/smallest appropriate machine
language." Yes, this is a change from the old PDP-11 days :-)