------- Comment #31 from jakub at gcc dot gnu dot org 2009-05-14 15:15 -------
Some -O2 code size data from today's trunk bootstraps. The first .text line
is always vanilla bootstrap, the second one with
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00702.html
only, the third one with that patch and
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00703.html
and the last with additional:
--- i386.c.jj3 2009-05-14 12:41:24.000000000 +0200
+++ i386.c 2009-05-14 14:48:24.000000000 +0200
@@ -27202,7 +27202,7 @@ x86_function_profiler (FILE *file, int l
static int
min_insn_size (rtx insn)
{
- int l = 0;
+ int l = 0, len;
if (!INSN_P (insn) || !active_insn_p (insn))
return 0;
@@ -27222,7 +27222,8 @@ min_insn_size (rtx insn)
&& symbolic_reference_mentioned_p (PATTERN (insn))
&& !SIBLING_CALL_P (insn))
return 5;
- if (get_attr_length (insn) <= 1)
+ len = get_attr_length (insn);
+ if (len <= 1)
return 1;
/* For normal instructions we may rely on the sizes of addresses
@@ -27230,6 +27231,9 @@ min_insn_size (rtx insn)
This is not the case for jumps where references are PC relative. */
if (!JUMP_P (insn))
{
+ if (get_attr_type (insn) != TYPE_MULTI)
+ return len;
+
l = get_attr_length_address (insn);
if (l < 4 && symbolic_reference_mentioned_p (PATTERN (insn)))
l = 4;
to see how the code size changes with much more accurate (though sometimes not
minimum but maximum bound) insn sizing for the algorithm.
64-bit cc1plus
[12] .text PROGBITS 000000000047f990 07f990 8c3ba8 00 AX
0 0 16
[12] .text PROGBITS 000000000047f990 07f990 89b1e8 00 AX
0 0 16
[12] .text PROGBITS 000000000047f9c0 07f9c0 899f78 00 AX
0 0 16
[12] .text PROGBITS 000000000047f9c0 07f9c0 88eaf8 00 AX
0 0 16
32-bit cc1plus
[12] .text PROGBITS 080b24e0 06a4e0 8f8cac 00 AX 0 0
16
[12] .text PROGBITS 080b24e0 06a4e0 8d516c 00 AX 0 0
16
[12] .text PROGBITS 080b2510 06a510 8d507c 00 AX 0 0
16
[12] .text PROGBITS 080b2510 06a510 8cbd7c 00 AX 0 0
16
For 64-bit cc1plus that's 1.8%, 1.86%, 2.36% smaller binary with the 1, 2 resp.
3 patches, for 32-bit cc1plus 1.55%, 1.56%, 1.96% smaller binary.
So the first patch is the most important and something like the third one,
perhaps with more exceptions, also makes a difference. I'll now try to update
my awk script to check for the AMD rules, namely that the last byte of the
branch insn counts rather than the first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
