wip patch: Create SymbolBody for all symbols

[Rafael Espíndola via llvm-commits]

And the third one now is at

http://reviews.llvm.org/D18056

Cheers,
Rafael


On 10 March 2016 at 09:27, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 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