PGO enhancements in GCC

[Jim Wilson]

Vincent Diepeveen wrote:
> The code size of the program in question i refer to here is DIEP and it's
> pretty big code size. It won't fit easily in L1 instruction cache of my K7
> processors (2x dual K7). Using profile guided information and structure of
> which function calls which it might be possible to reschedule the functions
> within the software such that it has a bigger chance to hit the functions
> already inside L1 instruction cache.

We have basic-block reordering pass that will move infrequently executed 
code out of line, so that frequently executed code is more likely to be 
in the cache.

There is certainly more that could be done though.  Moving functions 
around, so that a related functions are likely to be on the same page. 
Or so that related functions map to different parts of the cache.  We 
don't have this, as gcc primarily does one function at a time, plus this 
is more of a link-time problem than a compile time problem.

The compiler could do more cache optimizations if we need the size and 
structure of the cache, but we would need that info for a lot of 
different targets, and it would be hard to collect the info.

Most gcc work gets done by FSF volunteers, so we have no control over 
what optimizations get implemented or when they get implemented. 
Something will get implemented when a volunteer writes code to implement.

> The compile options i usually use when compiling with gcc are for first run
> and second run:

Gcc-3.4 will have -fprofile-generate and -fprofile-use options that will 
  choose good defaults for what optimizations to enable when using PGO.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com