On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
Also having some testcases showing inlining deffects in GCC would be very interesting for me. Now after IPA-SSA has been merged, I plan to do some retuning of inliner for 4.3 release since a lot has changes about properties of it's input and it was originally designed to operate well on IL used by early tree-ssa.
Gcc, well g++ really, used to be so bad at the inlining game, ie single op functions/ctors suddendly left out, there was no other options than to explicitly direct inlining if one cared about performance. So i don't have much to show, for what i monitored wasn't under g++ juridiction. Now i know it has improved (much) because obviously other parts are being stressed.
Considering information about stack frame size in the inlining costs is one of things I believe we should do but it is also dificult to tune without interesting testcases for it.
I have no idea what would make such testcase interesting to you. But i can try. You'll find 2 preprocessed GPLed sources attached with frontend.cc, app::frontend_loop() (i don't particularly care about that function, but on ia32 - x86-64 is immune - g++ is quite creative about it (large frame, oodles of upfront zeroing, even if it's a bit better with the gcc-4.3-20070119 snapshot)) frame size, msvc 1152 bytes, icc 2108, g++ 2604 rt_render_packet.cc, horde::grunt_render_tiles_packet(...) (this one i care about, inlining is controlled) frame size, msvc 1688, icc 1804, gcc 1932 Performance wise on that one msvc lags by 25% and gcc has a slight lead of a couple percent on icc. note: take 2, http://ompf.org/vault/frontend.ii.bz2 http://ompf.org/vault/rt_render_packet.ii.bz2
