wip patch: Create SymbolBody for all symbols

Rafael Espíndola via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 10 06:27:21 PST 2016


I have rebased the patch and uploaded it to
http://reviews.llvm.org/D18042. The next patch in the series is in
http://reviews.llvm.org/D18043

Cheers,
Rafael


On 10 March 2016 at 07:36, 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()).
>
> Cheers,
> Rafael


More information about the llvm-commits mailing list