wip patch: Create SymbolBody for all symbols

[Rui Ueyama via llvm-commits]

On Thu, Mar 10, 2016 at 4:36 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> On 9 March 2016 at 23:51, Rui Ueyama <ruiu at google.com> wrote:
> > 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?
>
> But it still returns itself as a repl. So a hot code path went from
> checking a value with null to checking a field of the returned pointer
> (Body.isLocal()).
>

I expect that after this change, we will be removing many isLocal()
function calls because in many places we will be able to handle local and
global symbols in the same way (because they will be represented in the
same data structure.) Does this affect the performance?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160310/b1176689/attachment.html>