This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR 16373: -fomit-frame-pointer when optimizing on x86
- From: Roger Sayle <roger at eyesopen dot com>
- To: Chris Lattner <sabre at nondot dot org>
- Cc: "Joseph S. Myers" <jsm at polyomino dot org dot uk>, <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 11 Jul 2004 18:45:21 -0600 (MDT)
- Subject: Re: [PATCH] PR 16373: -fomit-frame-pointer when optimizing on x86
On Sun, 11 Jul 2004, Chris Lattner wrote:
> > Do you have any doubt at all that this patch won't improve run-time,
> > reduce code size and speed up a bootstrapped compiler? :>
> Yes. It's quite likely to substantially increase code size. Almost every
> reference to the stack will have to be relative to the ESP register.
> References like [ESP+10] are substantially larger than the
> equivalent [EBP-10] encoding because the SIB encoding must be used.
> Food for thought,
This is a fair concern. I've just benchmarked the code size effect of
the patch, using the CSiBE v1.0.1 benchmark and the default "-Os" flags.
The total code size on i686-pc-linux-gnu drops from 939614 to 933795
(or by about 0.62%).
The first few differences look like:
bzip2,blocksort 7025 6305
bzip2,bzip2 16221 16069
bzip2,bzip2recover 3397 3365
bzip2,compress 9532 8998
bzip2,decompress 8216 8294*
bzip2,dlltest 675 671
bzip2,huffman 1107 1054
bzip2,mk251 30 24
bzip2,spewG 284 272
bzip2,unzcrash 912 908
catdvi,adobe2h 33622 33636*
catdvi,bytesex 790 774
catdvi,canvas 2668 2630
catdvi,catdvi 3933 3926
catdvi,density 2041 2006
catdvi,fixword 123 115
Hence although there are a few regressions (marked with an asterisk)
overall omitting the frame-pointer is a code-size win. I will however
admit that the stripped "cc1" binary grows from 4986396 bytes to
5002748 bytes (or about 0.33%), but I'm not sure if a little of this
isn't caused by the longer pathnames in the "patcho" directory than
the "clean" directory.