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

[dewar at gnat dot com (Robert Dewar)]

> That would be a disaster on STL-like code where function-object's
> operator() are commonly defined in the enclosing class.  I can't see
> any compeling reason why we should introduce that artificial distinction

I think there is an argument for a differentiation here. If a programmer
specifies inline, I think the compiler should be more ready to inline it.
In my experience, the compiler does too much inlining at -O3, and often
slows things down, so perhaps the automatic threshhold should be reduced,
but I don't think that is a good reason for reducing the threshhold for
an explicit inline. I am not ready to agree with people who think that
inline must always be obeyed, but I do think the compiler should go to
extra efforts to follow the (hopefully informed) hints from the user.


If one had infinite knowledge, the threshhold would depend on how often
the function is called. The compiler doesn't know that, so it can't make
the threshhold depend on this. But if there is an explicit inline, it is
reasonably taken as a hint that the frequency will be significant, so it
makes sense to have a higher thresshhold.

As for "disaster" on STL, that seems a bit overheated. Obviously you want
to set the thressholds to prevent disaster :-)