[PATCH] Decrease excessive string literal alignment on IA-32/AMD64

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Jan 21, 2004 at 10:05:06AM -0800, Richard Henderson wrote:
> On Wed, Jan 21, 2004 at 04:34:25AM -0500, Jakub Jelinek wrote:
> > I don't see anything which could take advantage of alignments bigger than
> > word size.
> 
> I can only assume someone was thinking it would make it easier
> for an sse-based str/memcpy.
> 
> > What do you think about either removing those 3 lines altogether
> > (allowing string literal suffix merging to be really effective even on
> > longer strings), or s/256/BITS_PER_WORD/ (suffix merging would only
> > work between strings with equal sizes modulo UNITS_PER_WORD and not between
> > really short and long strings), or s/256/BITS_PER_WORD/ and add
> > !optimize_size, so that -Os makes the alignment 1?
> 
> I think the choice between BITS_PER_WORD and BITS_PER_UNIT (not 1!)
> depends on how much merging we can show for your average application.

I've gathered some statistics from gcc34 compiled 2.6.1 kernel:

vmlinux, large strings aligned to 32B, constant merging in ld hacked out:

.rodata.str1.1: size 70984 bytes, 5500 strings, 67 bytes padding
.rodata.str1.32: size 136505 bytes, 2002 strings, 35980 bytes padding
total: size 207489 bytes, 7502 strings, 36047 bytes padding

the same, but stock linker (i.e. section merging works):
.rodata.str1.1: size 49330 bytes, 3631 strings, 106 bytes padding
.rodata.str1.32: size 129209 bytes, 1900 strings, 34126 bytes padding
total: size 178539 bytes, 5531 strings, 34232 bytes padding

vmlinux, large strings aligned to 4B, constant merging in ld hacked out:

.rodata.str1.1: size 80463 bytes, 5690 strings, 67 bytes padding
.rodata.str1.4: size 93741 bytes, 1812 strings, 2682 bytes padding
total: size 174204 bytes, 7502 strings, 2749 bytes padding

with constant merging:
.rodata.str1.1: size 58765 bytes, 3820 strings, 106 bytes padding
.rodata.str1.4: size 88149 bytes, 1711 strings, 2487 bytes padding
total: size 146914 bytes, 5531 strings, 2593 bytes padding

vmlinux, all strings aligned to 1B, with constant merging:

.rodata.str1.1: size 143814 bytes, 5500 strings, 106 bytes padding
.rodata.str1.4: size 115 bytes, 3 strings, 0 bytes padding
total: size 143929 bytes, 5503 strings, 106 bytes padding

Padding above means number of '\0' bytes in the section not
counting the terminating '\0' characters of the string.
Why there is any padding in .rodata.str1.1 sections after merging
is very surprising and I'll look at it later.

This shows that when going from 32B aligned large strings to 4B
aligned large strings, there were no further suffix merging opportunities
in LK, but going down to 1B there were 28 new suffix merges, but they
saved only 498 bytes (the remaining 2487 saved bytes when going from
4B to 1B alignment were saved in padding).

The first 2 objects were created with stock GCC, the remaining ones
with following patch applied (the last was an -Os build, the remaining
ones were -O2).

I think 1B alignment for -Os and sizeof (void *) for -O2 makes most sense
for IA-32 and AMD64.
Ok to commit (trunk/branch)?

2004-01-26  Jakub Jelinek  <jakub@redhat.com>

	* config/i386/i386.c (ix86_constant_alignment): Decrease alignment
	of long string literals from 32 bytes to sizeof (void *) when !-Os
	and to 1 with -Os.

--- gcc/config/i386/i386.c.jj	2004-01-21 09:54:52.000000000 +0100
+++ gcc/config/i386/i386.c	2004-01-21 21:04:28.000000000 +0100
@@ -12499,9 +12499,9 @@ ix86_constant_alignment (tree exp, int a
       else if (ALIGN_MODE_128 (TYPE_MODE (TREE_TYPE (exp))) && align < 128)
 	return 128;
     }
-  else if (TREE_CODE (exp) == STRING_CST && TREE_STRING_LENGTH (exp) >= 31
-	   && align < 256)
-    return 256;
+  else if (!optimize_size && TREE_CODE (exp) == STRING_CST
+	   && TREE_STRING_LENGTH (exp) >= 31 && align < BITS_PER_WORD)
+    return BITS_PER_WORD;
 
   return align;
 }


	Jakub