Re: ridiculous amounts of padding

[Joern Rennecke <amylaar at cygnus dot co dot uk>]

> Since everyone is discussing string functions...
> 
> Code of the form
> 
> puts("line 1");
> puts("line 2");
> puts("line 3");
> ...
> puts("line 96");
> 
> is compiled (at least on x86) into a series of calls and a bunch of string
> table entries.  Fine.  The problem is, in the string table we emit
> .align 32 directives between all the strings.  This wastes quite a lot of
> space.  It seems that this is because of a general policy of aligning
> .rodata items on 32 byte boundaries - I assume for cache reasons.  When we
> know, as in this case, that all the strings will be accessed in succession,
> I think we should be able to remove the padding.  (Kaveh's suggested
> collapse-to-one-call optimization would be good too.)

This sounds like a hard pproperty to verify, and it won't be true very often
overall.
A different approach would be to only do the alignment if it reduces the
total number of cache lines the data item ends up in.  We need support
from the assembler with a .align directive that supports a maximum
alignment padding.  If we name the cache line size as CLS (32 for the
above target), and the data items size as SIZE, the max padding is:
(SIZE - 1) & CLS

Thus, if you have a sucession of short strings, you can expect to get only
a few and relatively small paddings there.

Of course, we still want to align the start of the section, to avoid
having a cache line that spans text and rodata section, since that
leads to poor performance on processors with separate data and instruction
caches.