[PATCH] D13958: Mere SHF_STRING

[Joerg Sonnenberger via llvm-commits]

On Fri, Oct 23, 2015 at 10:05:30AM -0700, Rui Ueyama via llvm-commits wrote:
> On Fri, Oct 23, 2015 at 6:12 AM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
> 
> > > Good numbers. We are probably already on per with gold in terms of output
> > > size. (It's actually more than per, so we may be discarding too much data
> > > with --gc-sections, but I don't know what that is. At least all tests
> > still
> > > pass.)
> >
> > That was .eh_frame.
> >
> > > This feature makes LLD about 1.5x slower. Does this feature have to be
> > > enabled by default? It feels like it's a kind of -O1 feature for linkers.
> >
> > Most linkers do put it in -O1. With the current ADT
> > (StringTableBuilder) it is not that easy to make it optional.
> >
> 
> My feeling is that because this is a heavy optimization (30% increase of
> link time), linkers should not do unless it is told to do so by a command
> line option, just like --gc-sections. It doesn't seems correct to me that
> existing linkers merge SHF_MERGE sections as long as they exist.

There is quite a difference in that --gc-sections can change program
behavior. There are various programs that have been broken like it, just
like --as-needed did.

Do we have any good isolated (performance) unit test for the String
Builder?

Joerg