wip patch: Create SymbolBody for all symbols

[Rui Ueyama via llvm-commits]

I think this is towards a good direction, but I want to understand what is
going on more as 9% slowdown is somewhat significant.

On Wed, Mar 9, 2016 at 7:11 PM, Rafael Espíndola <rafael.espindola at gmail.com
> wrote:

> OK, looking at perf, what I got was that the "slow" instructions were
>
>
> mov    (%rcx,%rax,8),%rax
> mov    0x28(%rax),%rax
> mov    (%rax),%r13
>
> Which correspond to:
>  * given a symbol index, get the SymbolBody*
>  * get the backref
>  * get the repl
>
> I think these are only slow because we then proceed to use the data
> and pref blames the instruction that is computing the dependency of an
> expensive computations.
>

Unless added to the symbol table, SymbolBodies does not have backrefs.
Their backrefs are nullptrs. So I think for local symbols, that code would
not be executed. Is this actually a bottleneck for local symbols?


> The slowdown is because previously for local symbols we would branch
> out on the body being null.
>
> This suggests possible speed improvements:
> * Allocate SymbolBodies inline, like we do for SharedFile.
> * Use a bit of the pointer to cache if the SymbolBody is local or not.
>
> Given that there is a reasonable understanding, that other benchmarks
> (scylla) actually got faster and that the slowdown is not inherently
> because of the extra allocation, is the patch OK?
>
> Cheers,
> Rafael
>
>
>
> On 9 March 2016 at 18:21, Rafael Espíndola <rafael.espindola at gmail.com>
> wrote:
> > llvm.org/pr26878 has a case where we need to put a local symbol in the
> > got. Given that we have to allocate something to remember the got
> > index.
> >
> > One way to do it is to create SymbolBodies. The attached patch does it
> > an has the potential of further simplifications.
> >
> > Unfortunately with it I am seeing a 1.09X slowdown when linking clang.
> > The link line has --export-dynamic -O3 --gc-sections.
> >
> > Cheers,
> > Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160309/dfc36ff2/attachment.html>