> On 1/28/07, tbp <[EMAIL PROTECTED]> wrote: > >Let it be clear from the start this is a potshot and while those > >trends aren't exactly new or specific to my code, i haven't tried to > >provide anything but specific data from one of my app, on > >win32/cygwin. > > > >Primo, gcc getting much better wrt inling exacerbates the fact that > >it's not as good as other compilers at shrinking the stack frame size, > >and perhaps as was suggested by Uros when discussing that point a pass > >to address that would make sense. > >As i'm too lazy to properly measure cruft across multiple compilers, > >i'll use my rtrt app where i mostly control large scale inlining by > >hand. > >objdump -wdrfC --no-show-raw-insn $1|perl -pe 's/^\s+\w+:\s+//'|perl > >-ne 'printf "%4d\n", hex($1) if /sub\s+\$(0x\w+),%esp/'|sort -r| head > >-n 10 > > > >msvc:2196 2100 1772 1692 1688 1444 1428 1312 1308 1160 > >icc: 2412 2280 2172 2044 1928 1848 1820 1588 1428 1396 > >gcc: 2604 2596 2412 2076 2028 1932 1900 1756 1720 1132 > > It would have been nice to tell us what the particular columns in > this table mean - now we have to decrypt objdump params and > perl postprocessing ourselves. > > (If you are interested in stack size related to inlining you may want > to tune --param large-stack-frame and --param large-stack-frame-growth).
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. 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. Honza > > Richard.