Re: [patch] ld speedup 1/3 (suffix merge)

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Sep 19, 2003 at 11:47:42AM +0200, Michael Matz wrote:
> Hi,
> 
> On Thu, 18 Sep 2003, Jakub Jelinek wrote:
> 
> > I should note that alignment > entsize merging is important.
> 
> I believe we didn't see this because the only 'M' section I could find
> where the .debug_str ones.  This was with gcc 3.3.x and only on x86.  So
> we actually emit also other mergable section?  Good, because I already
> found the complicatedness in handling alignment a bit funny when it
> isn't used  ;-)

All string literals go to .rodata.strM.N sections if optimizing
(where M is sizeof(*string_literal) and N alignment of the strings).
Similarly, floating point constants (.rodata.cstN)
and if -fmerge-all-constants, also read-only variables.
As GCC generates things (ie. for different alignments use different
N in the section name) all mergeable sections which are to be merged
together will have the same alignment (and the strings within).
But it can happen that one writes by hand:
	.section .rodata.str,"aMS",@progbits,1
.LC1:	.string "abcd"
in one file and
	.section .rodata.str,"aMS",@progbits,1
	.align 4
.LC2:	.string "defabcd"
in another file, links together, or if one writes:
	.section .rodata.str,"aMS",@progbits,1
.LC3:	.string "abcd"
.LC4:	.string "defg"
.LC5:	.string "efabcd"
	.align 4
.LC6:	.string "efdefg"
	.align 4
.LC7:	.string "bcabcd"
Then the strings don't have the same alignment in the same mergeable section
(but in that case I think it is authors problem that not all possible
merges will happen). 

	Jakub