This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> always_inline is just extra clutter, either in the sources or in the Makefile.

I disagree. I think that always_inline should be used *only* if there is a 
functional requirement (not just an efficiency requirement) for inlining. And
such situations are unusual, and to me require a specific comment anyway, so
if you have a specific comment, it may as well be attached to the
attribute specification.

> This breaks existing programs; not in the sense of
> causing them to fail to compile or work, but by causing severe performance
> regressions.

But if there are "severe performance regressions" caused by the compiler not
recognizing inline when it should, that's a serious problem that should be
addressed, not by a kludge requiring programmer messing, but by fixing the
compiler. For addressing that, it would seem to me that examples woul dbe
most useful.

One interesting point here is that in the case of Ada, we find that the
compiler makes quite reasonable decisions for pragma Inline, it does not
*always* inline every instance of pragma Inline, which is why we have
Always_Inline, and in particular, we require a switch to activate inlining,
and Always_Inline inlines even in the absence of this switch. But the
heuristics used for inlining seem to work pretty well. Indeed the only
trouble we have had with inlining is people using -O3 and degrading
performance, since -O3 typically does too much inlining, especially in
a program where the programmer has already decided what should be inlined.

> It's the change in behaviour from previous versions that bothers me

That's certainly a legitimate concern. I think the most useful thing would
be real examples where there is a significant change in performance, since
the objective should be to improve the handling of inline by default.

> this is the reason why I would like something like -fobey-inline as default.

That seems undesirable to me, there may be legitimate reasons for refusing
to inline a function (e.g. performance reasons, if you have a huge function
with many calls, then the code explosion is very likely to degrade
performance by degrading icache performance).
y
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]