Because we also generate the "driver function" that calls these class member functions in a particular order,
we generate the C++ functions in a linear order that is identical to the order in which the functions are called.
e.g. if we had
class a { static void fx(); static void fy(); }; class b { static void fx(); static void fy(); }
and the order that the functions were called was
a::fy(); b::fy(); b::fx() a::fx();
Then we would generate a C++ source file containing
void a::fy() {...} void b::fy() {...] void b::fx() {...} void a::fx() {...}
This is a win for paging and cache-line prefetching - essentially it's compile-time profile-guided optimization.
With 3.3, the functions are in fact emitted as assembly language in the order in which they were declared.
With 3.4, this is not true - functions are not emitted in the order that they were defined in the source file.
We have measured a 5-9% degradation in execution time and suspect that this is the source of the problem.
I've tried -fno-unit-at-a-time (and that leads to worse performance - perhaps a 10% SLOWER gcc 3.4.3). Is there any other way to control function ordering (short of compiling each function to a separate section and writing linker language that orders the sections in the order we want)?
I can't see any other compiler switches that would affect this other than perhaps -fno-reorder-functions, and that seems to hurt performance as well.