Re: Reordering of functions

> Maybe. You've set up a straw-man where you have tried to deny all
> ways that changing the order of function calls might affect
> preformance and then asked will performance remain unchanged.
> However, even in your denial you have left holes open, what about
> machines the execute a limited number of instructions out-of-order and
> use register renaming. That's a cache-like effect (just like
> pre-fetching, and branch prediction are). Reordering the function
> calls can influence all of those.


I agree with you on that. That's obvious. But I was actually talking
about the rearrangement of functions in memory while the order of
function invocations remains the same.


> Finally, some of the effects are hard to quantify and/or predict. When I
> was working on the Alpha optimizer, there were some optimizations we
> specifically turned on (and off) in specific orders because they had an
> unfortunate interaction on one of the benchmarks we were measuring
> against. The right combination of optimizations yielded a fortuitous
> alignment of a critical loop, that was lost if we did (a little) more
> optimization until we got significantly more optimizations enabled and
> could remove enough code that the loop was always aligned.


Finding the right combination of optimizations which yields good
results for a set of different programs seems to be an unsolvable
problem. How do compiler designers decide which combinations/sequences
of optimizations seem to be promising and are put together into an
optimization level (like gcc's -O)?


Is this an trial-and-error approach assisted with some experience?


One "solution" I know is the ACOVEA project which uses an genetic
algorithm to find the "best" gcc options for a particular program
under test. But this is a particular case where you want to achieve
best results for one application.


Regards,
Tim

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