RFC Decrease excessive string literal alignment on IA-32/AMD64

RFC Decrease excessive string literal alignment on IA-32/AMD64

[Jakub Jelinek]

Hi!

IA-32/AMD64 uses alignment 32 for string literals with strlen () >= 31.
E.g. on Linux kernel I've picked up this wastes at least 32K of
non-swappable space.
This alignment also means that for longer strings almost no suffix merging
can be done by the linker (it can be done only if one string is a suffix of
the other one, but both are longer than 31 chars and they have equal lengths
modulo 32).

  else if (TREE_CODE (exp) == STRING_CST && TREE_STRING_LENGTH (exp) >= 31
           && align < 256)
    return 256;

I don't see anything which could take advantage of alignments bigger than
word size.  E.g. glibc/Linux kernel's string ops don't care about alignments
bigger than word size (well, e.g. glibc memcpy won't be any faster if it is
alignmed) and I don't see GCC generating code which could make use of it
either.  Say even on very unrealistical example where the target of
memcpy/strcpy is already 32 bytes aligned:

/* { dg-options "-O2 -march=pentium4 -msse2" } */
char buf[128] __attribute__((aligned (32)));
#define TEN "0123456789"
#define HUNDRED TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define ONETWENTYEIGHT HUNDRED TEN TEN "0123456"
#define THIRTYTWO TEN TEN TEN "0"
#define SIXTYFOUR TEN TEN TEN TEN TEN TEN "0123"

void foo1 (void)
{
  __builtin_memcpy (buf, ONETWENTYEIGHT, 128);
}

void foo2 (void)
{
  __builtin_memcpy (buf, THIRTYTWO, 32);
}

void foo3 (void)
{
  __builtin_memcpy (buf, SIXTYFOUR, 64);
}

nothing cares about string literal alignment.

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?

	Jakub

Re: RFC Decrease excessive string literal alignment on IA-32/AMD64

[Richard Henderson]

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.


r~