------- Comment #8 from xinliangli at gmail dot com 2008-03-12 07:17 ------- (In reply to comment #5) > For reference see: > http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01205.html > http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00200.html > http://gcc.gnu.org/ml/gcc/2005-12/msg00215.html > > And most likely a couple others too. I cannot find a good reference > explaining > why early inline helps a lot for C++ code like tramp3d. > > >Again, how much performance gain can be achieved with early optimization for > instrumented binary (which is slow anyway)? > > IIRC there was a huge win (like a 10x speedup) for doing this. >
Yes, that is actually likely for C++ apps. For the compiler I worked with before, the default optimization level is -O1 which performs user directed inlining -- so the implicit requirement for instrumentation is actually -O1 and above. > > > At least it is tricky with cross module inlining happening for instrumented > > functions -- the inline instances should really updating counters in the > > original routines. > > Depends on if the inline is done with early inline or late and really really > if > it is done with late, the counters will be emitted with the LTO file before > reading them back in so the counters will be correct already and inlining > becomes obvious. > I was referring to cross module inlining that happens late. Looks like for gcc, this won't be an issue in theory. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35544
