Synchronization cost regression

Loren James Rittle rittle@latour.rsch.comm.mot.com
Mon Aug 6 15:46:00 GMT 2001


In article < Pine.LNX.4.10.10108041034220.3742-100000@mars.deadcafe.org >
Jeff Sturm writes:

> Somebody else mentioned that the c++ inliner heuristics have recently been
> tweaked.  That shouldn't affect an explicit inline.

Perhaps it should not affect explicit inline...

> But if this behavior persists it might be a good idea to file a PR.

...however, it currently does.

Try this example:

inline void f (void) {}

void g (void) { f (); }

g++ -S -fno-exceptions -O2 --param max-inline-insns=0 g.C

It will *not* inline f().  We might think that 0 is a special case,
thus try removing the explicit setting of the max-inline-insns
parameter and building a larger, non-trivial body for f().  At some
point, it will not inline even with the explicit inline keyword.

Some might call this a regression of some sort from 2.95.X and before.
FYI: This change occurred around the time or after we went from RTL
inlining to tree-based inlining...

The upshot is that when the default setting of max-inline-insns was
cranked *way* down, many large functions marked to be explicitly
inlined were no longer being inlined.

To directly answer Hans' original question, AFAIK, there is now no way
to force the compiler to inline something by source annotations.  You
must crank up the max-inline-insns parameter on the command line.

Regards,
Loren



More information about the Java mailing list