function code order changes from gcc-3.3 to 3.4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We have a tool that generates C++ code as a series of functions inside different classes.

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.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux