This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: remarks about g++ 4.3 and some comparison to msvc & icc on ia32
> On 1/28/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> >On 1/28/07, tbp <tbptbp@gmail.com> wrote:
> >> 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.
> I should have known better than to post on a sunday morning. Sorry.
> That's the sorted 10 largest stack allocations in binaries produced by
> each compiler (presuming most everything falls in place).
> Each time i verify codegen for a function across all 3, gcc always has
> the largest frame by a substantial amount (on ia32). And that's what
> that rigorous table is trying to demonstrate ;)
>
> Basically i'm wondering if a stack frame shrinking pass [ ] is
> possible, [ ] makes no sense, [ ] has been done, [ ] is planed etc...
Actually we do have one stack frame shrinking pass already. It depends
on where the bloat is comming from - we can pack (with some limitations)
memory used by structures/arrays used by different inline functions or
lexical blocks. We don't do any packing of spilled registers nor shring
wrapping other compilers sometimes implement.
Honza
>
> >(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).
> Recently g++ 4.3 has started to complain about "warning: inlining
> failed in call to 'xxx': --param large-stack-frame-growth limit
> reached [-Winline]. Bumping said large-function-growth by an ungodly
> amount did the trick. But it was the sure sign inlining was being
> fixed.
> There's much less need to babysit it, thanks a lot to whomever wrote
> those patches.