Re: Reordering of functions

Joel Yliluoma <>
19 Feb 2008 11:33:56 GMT

          From comp.compilers

Related articles
Reordering of functions (Tim Frink) (2008-02-18)
Re: Reordering of functions (Nikolai Kim) (2008-02-18)
Re: Reordering of functions (Joel Yliluoma) (2008-02-19)
Re: Reordering of functions (Chris F Clark) (2008-02-19)
Re: Reordering of functions (glen herrmannsfeldt) (2008-02-20)
Re: Reordering of functions (Tim Frink) (2008-02-21)
Re: Reordering of functions (Tim Frink) (2008-02-21)
Re: Reordering of functions (Tim Frink) (2008-02-21)
Re: Reordering of functions (glen herrmannsfeldt) (2008-02-24)
[3 later articles]
| List of all articles for this month |

From: Joel Yliluoma <>
Newsgroups: comp.compilers
Date: 19 Feb 2008 11:33:56 GMT
Organization: TDC Internet Services
References: 08-02-051
Keywords: optimize
Posted-Date: 19 Feb 2008 12:54:03 EST

On Mon, 18 Feb 2008 17:22:52 +0100, Tim Frink wrote:
> I've a question about the influence of compiler optimizations that
> reorder functions on the system performance.
> Assume a modern processor with all state-of-the art features like
> prefetching, branch prediction and a superscalar pipeline. Further
> assume that all caches are disabled. Will the program runtime change
> when just the order of functions is changed (without any other code
> transformation)?

Aren't "with branch prediction" and "caches are disabled" somewhat
mutually exclusive statements?

As I understand it, the processor does branch prediction based on
past experience (which is cached using some hash generated
from the instruction address), or lacking experience, heuristics.

If such cache exists, then function reordering might help in cases
where multiple functions have jumps in identically hashing addresses
with identical probabilities. I find that to be unlikely.

> I'm of the opinion that a reordering of function should have little
> influence on the program execution, maybe due to some prefetch effects
> but thes should be marginal. Of course, with caches this situation
> would look different.

Function reordering might help also in situations where the processor
supports jumps that are differently encoded depending on the jump length
(such as the bra/brl opcodes on 65c816, or similar on x86). If a tailcall
occurs to a function that is located within a short distance, it might
be faster with than a tailcall with a larger distance, because the opcodes

In any case, I think the effects of cache (and/or demand loading) are
greatly more significant than those which I listed, regarding the function

Joel Yliluoma -

Post a followup to this message

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