public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Questions on inlining of code
@ 1999-03-18  7:29 Steve Snyder
       [not found] ` < 199903181530.KAA01307@indy3.indy.net >
  1999-03-31 23:46 ` Steve Snyder
  0 siblings, 2 replies; 8+ messages in thread
From: Steve Snyder @ 1999-03-18  7:29 UTC (permalink / raw)
  To: EGCS Mailing List, PGCC Mailing List

Two question on inlining of code in egcs/pgcc:

1. Is it possible to disable automatic inlining (compiler switches -O3 or 
-finline) while still respecting the inline declaration in the source code?
I'd like to compile with max optimization (-O6) while avoiding the bloat 
that comes with aggressive inlining of code.  At the same time, though, I 
don't want to disabled the inlining of code explicitly declared as such.

2. Does aggressive inlining of code make any sense on a Pentium+ CPU?
It obviously helps on a 386/486 by avoiding the call/return instructions. 
I wonder, though, if the inlining of code doesn't just thrash the L2 cache 
on more recent processors.  Given the prevalence these days of 512kb L2 
caches, maybe inlining should not be automatically enabled by higher levels
of optimization?

Thank you.


*** Steve Snyder ***

^ permalink raw reply	[flat|nested] 8+ messages in thread
[parent not found: <199903181530.KAA01307.cygnus.egcs@indy3.indy.net>]
* Re: Questions on inlining of code
@ 1999-03-18 17:44 N8TM
  1999-03-31 23:46 ` N8TM
  0 siblings, 1 reply; 8+ messages in thread
From: N8TM @ 1999-03-18 17:44 UTC (permalink / raw)
  To: ssnyder, egcs, pgcc

In a message dated 3/18/99 7:31:44 AM Pacific Standard Time, ssnyder@indy.net
writes:

> 2. Does aggressive inlining of code make any sense on a Pentium+ CPU?
>  It obviously helps on a 386/486 by avoiding the call/return instructions. 
>  I wonder, though, if the inlining of code doesn't just thrash the L2 cache 
>  on more recent processors.  Given the prevalence these days of 512kb L2

I suspect your context is different from mine, but I would answer that in-
lining is likely to be useful only in inner loops.  I would point out also
that there is little benefit in going beyond -Os with the "stable release"
compilers, and seldom more than 10% with the snapshots.  Depending on your
source code, you may be able to exert some control over excessive in-lining by
splitting it into separately compiled files, using includes as necessary.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~1999-03-31 23:46 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-18  7:29 Questions on inlining of code Steve Snyder
     [not found] ` < 199903181530.KAA01307@indy3.indy.net >
1999-03-18  9:04   ` Jeffrey A Law
1999-03-31 23:46     ` Jeffrey A Law
1999-03-31 23:46 ` Steve Snyder
     [not found] <199903181530.KAA01307.cygnus.egcs@indy3.indy.net>
1999-03-18  8:33 ` Jason Merrill
1999-03-31 23:46   ` Jason Merrill
1999-03-18 17:44 N8TM
1999-03-31 23:46 ` N8TM

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).