Re: Is inlining evil?

hoelzle@neon.Stanford.EDU (Urs Hoelzle)
Sat, 4 May 1991 00:56:12 GMT

          From comp.compilers

Related articles
Is inlining evil? (Michael K. Gschwind) (1991-05-03)
Re: Is inlining evil? hoelzle@neon.Stanford.EDU (1991-05-04)
Re: Is inlining evil? (1991-05-04)
Re: Is inlining evil? (Clark Williams) (1991-05-05)
Re: Is inlining evil? (Marc Sabatella) (1991-05-08)
| List of all articles for this month |

Newsgroups: comp.compilers
From: hoelzle@neon.Stanford.EDU (Urs Hoelzle)
Keywords: optimize, design
Organization: Computer Science Department, Stanford University, Ca , USA
References: <> <> <19 <>
Date: Sat, 4 May 1991 00:56:12 GMT (Michael K. Gschwind) writes:

>Yes, inlining can result in performance degradation, esp. cache effects
>can be awful, but judicious use of inlining is a Good Thing. If you
>inline (modestly) huge functions (< 10-20 % of I - cache size (?)), this
>will destroy any hint of locality. Take this example of C code:

I keep seeing these ominous warnings about the Bad Things that happen
when code size increases. Does anybody actually have data on this? I
seem to remember one study where doubling the code size didn't change
the code cache miss ratio very much.

I suspect that with reasonably large I caches (say > 32K) code cache
misses are not an issue when deciding wether to use inlining or not.
Remember that doubling the I cache size doesn't buy you very much
above a certain (read: reasonable) cache size.


Disclaimer: sure, there will always be some cases where code size / I
cache behavior *is* important - but I think they are the exception
rather than the rule.

Urs Hoelzle hoelzle@cs.stanford.EDU
Center for Integrated Systems, CIS 42, Stanford University, Stanford, CA 94305

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.