Related articles |
---|
Is inlining evil? mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) (1991-05-03) |
Re: Is inlining evil? hoelzle@neon.Stanford.EDU (1991-05-04) |
Re: Is inlining evil? quale@cs.wisc.edu (1991-05-04) |
Re: Is inlining evil? clark@ingr.com (Clark Williams) (1991-05-05) |
Re: Is inlining evil? mjs@hpfcso.fc.hp.com (Marc Sabatella) (1991-05-08) |
Newsgroups: | comp.compilers |
From: | Clark Williams <clark@ingr.com> |
Keywords: | optimize, design |
Organization: | Compilers Central |
References: | <1991May4.005612.7207@neon.Stanford.EDU> |
Date: | Sun, 5 May 91 15:31:58 -0500 |
hoelzle@neon.Stanford.EDU (Urs Hoelzle) writes:
>
> 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.
>
Also, what about the case of expanding code size to take advantage of a
deep pipeline? Isn't this working at cross purposes with attempting to
maintain locality of reference? If you insert instructions into the
instruction stream to keep the pipe full, are you shooting yourself in
the foot as far as the cache hit rate is concerned?
Has anyone run into this issue before?
Clark Williams
Intergraph Corp.
...uunet!ingr!clark (UUCP)
clark@ingr.com (Internet)
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.