This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: LNO Branch merge proposal
On Wed, 17 Mar 2004, David Edelsohn wrote:
> LNO will not be enabled by default, so it cannot have any impact
> on compile time, run time, or memory consumption. Only diskspace. High
Increased code size can affect compile-time performance, if nothing else
because we don't sort functions in the executable to optimise cache
performance. Look at the increasing size of cc1, which could well
contribute to slow performance degradation (on i686-pc-linux-gnu):
text data bss dec hex version
1026014 16996 68808 1111818 10f70a 2.7.2.3
1286049 19668 73884 1379601 150d11 2.8.1
1296058 19632 69772 1385462 1523f6 egcs-1.0.3a
1438977 18188 78328 1535493 176e05 egcs-1.1.2
1653481 16856 86820 1757157 1acfe5 2.95.3
2439922 15036 434136 2889094 2c1586 3.0.4
2889499 6192 692608 3588299 36c0cb 3.2.3
3083133 2624 746656 3832413 3a7a5d 3.3.3
3464870 3192 529120 3997182 3cfdfe 3.4 branch
(mainline omitted since I don't have a --disable-checking mainline
compiler to hand to compare)
That said, I'd rather see features that require special flags to enable
them present on mainline rather than on a branch with all the merging that
implies. I've wondered why new-regalloc development sits on a branch
(with bug reports from people testing -fnew-ra other than on that branch
being fairly useless) when -fnew-ra is needed to enable the new allocator.
--
Joseph S. Myers
jsm@polyomino.org.uk