This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -fobey-inline (was Re: gcc and inlining)
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Robert Dewar <dewar at gnat dot com>
- Cc: Richard dot Earnshaw at arm dot com, bernds at redhat dot com, aph at redhat dot com,gcc at gcc dot gnu dot org
- Date: Sat, 15 Mar 2003 13:35:38 -0500
- Subject: Re: -fobey-inline (was Re: gcc and inlining)
- References: <20030315182745.25C6CF2D4F@nile.gnat.com>
On Sat, Mar 15, 2003 at 01:27:45PM -0500, Robert Dewar wrote:
> > 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.
Several have already been posted in this thread, including one
C++-heavy test which requires inlining limits probably considerably
higher than are "generally" appropriate.
After the most recent inlining patches, we have a mechanism to set
different thresholds for automatic and explicit inlining, I believe.
Whatever is decided about -fobey-inline, I suspect that the explicit
(max_inline_insns_single?) threshold needs to be bumped _way_ up.
> > 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).
Sure. The programmer had better know that if he's marking things
inline.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer