[llvm-dev] [lld] We call SymbolBody::getVA redundantly a lot...

[Rui Ueyama via llvm-dev]

I don't think getVA is particularly expensive, and if it is not expensive I
wouldn't cache its result. Did you experiment to cache getVA results? I
think you can do that fairly easily by adding a std::atomic_uint64_t to
SymbolBody and use it as a cache for getVA.

On Tue, Feb 28, 2017 at 4:19 AM, Sean Silva <chisophugis at gmail.com> wrote:

> tl;dr: it looks like we call SymbolBody::getVA about 5x more times than we
> need to
>
> Should we cache it  or something? (careful with threads).
>
>
> Here is a link to a PDF of my Mathematica notebook which has all the
> details of my investigation:
> https://drive.google.com/open?id=0B8v10qJ6EXRxVDQ3YnZtUlFtZ1k
>
>
> There seem to be two main regimes that we redundantly call
> SymbolBody::getVA:
>
> 1. most redundant calls on the same symbol (about 80%) happen in quick
> succession with few intervening calls for other symbols. Most likely we are
> processing a bunch of relocations right next to each other that all refer
> to the same symbol (or small set of symbols); e.g. within a TU
>
> 2. there is a long-ish tail (about 20% of calls to SymbolBody::getVA)
> which happen at a long temporal distance from any previous call to
> SymbolBody::getVA on the same symbol. I don't know off the top of my head
> where these are coming from, but it doesn't sound like relocations. A quick
> grepping shows a bunch of source locations that match getVA, so it's hard
> at a glance to see. Any ideas where these other calls are coming from?
>
> The particular link I was looking at was a release without debug info
> link, using `-O0 --no-gc-sections --no-threads`. The particular test case
> is LLD itself.
>
> -- Sean Silva
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170228/6a378b9f/attachment.html>