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...