Re: remarks about g++ 4.3 and some comparison to msvc & icc on ia32

[tbp <tbptbp at gmail dot com>]

On 1/28/07, Jan Hubicka <hubicka@ucw.cz> 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