On Sun, 2009-02-15 at 01:36 -0500, Gregory Maxwell wrote: > Sadly, the profiles are fairly tied to the source code. > (This is the same data that gcov uses, so you can look at the gcov manpage > for more information) > > GCC complains loudly if they don't match exactly, and any line number offset > will scramble the profiling and likely give worse performance than without > profile driven optimization at all. This is quite unfortunate because I like > the idea of distributing the profile along with the source since that means > the compilation would be more easily reproducible. > > (and keeping profile generation out of the build system is probably a > precondition for this kind of thing ever seeing widespread use) I think a better option is to just borrow a trick from the Linux kernel: http://kerneltrap.org/node/4705 Just putting the optimization hints directly in the source solves all these problems. I've done this in an upcoming OpenJPEG patch: /* A convention borrowed from the Linux kernel. Provides gcc with branch optimization hints. */ #ifdef __GNUC__ #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0) #else #define likely(x) (x) #define unlikely(x) (x) #endif
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
