search for: r263227

...ions that call TargetInfo's member >> functions for each target to eliminate the virtual function calls. >> > > From what has been presented I would not conclude that virtual calls are > actually the problem (or a problem at all). A root-cause analysis is > necessary. As r263227 shows, the relocation application loop is very > sensitive to small changes. > > One quick thing you may also want to try as a sanity check is inserting > nops in different places in the function. I suspect you'll find that the > performance swings (both speedups and slowdowns) f...

...o's member >>> functions for each target to eliminate the virtual function calls. >>> >> >> From what has been presented I would not conclude that virtual calls are >> actually the problem (or a problem at all). A root-cause analysis is >> necessary. As r263227 shows, the relocation application loop is very >> sensitive to small changes. >> >> One quick thing you may also want to try as a sanity check is inserting >> nops in different places in the function. I suspect you'll find that the >> performance swings (both speed...

...(certainly nothing that would cause 1.8% performance > delta for the entire link). > Agreed. We could template functions that call TargetInfo's member functions for each target to eliminate the virtual function calls. > Notice that 1.8% is smaller than the performance variation from r263227 > which is a very innocuous-looking change but caused ~2-3% slowdown for > ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and > --build-id)"). > > -- Sean Silva > > On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.l...

...We could template functions that call TargetInfo's member > functions for each target to eliminate the virtual function calls. > >From what has been presented I would not conclude that virtual calls are actually the problem (or a problem at all). A root-cause analysis is necessary. As r263227 shows, the relocation application loop is very sensitive to small changes. One quick thing you may also want to try as a sanity check is inserting nops in different places in the function. I suspect you'll find that the performance swings (both speedups and slowdowns) from doing that are simil...

...gt;> functions for each target to eliminate the virtual function calls. >>>> >>> >>> From what has been presented I would not conclude that virtual calls are >>> actually the problem (or a problem at all). A root-cause analysis is >>> necessary. As r263227 shows, the relocation application loop is very >>> sensitive to small changes. >>> >>> One quick thing you may also want to try as a sanity check is inserting >>> nops in different places in the function. I suspect you'll find that the >>> performanc...

...he current scheme, since the target is fixed, all the indirect call sites should be monomorphic and so there shouldn't be much branch-prediction cost (certainly nothing that would cause 1.8% performance delta for the entire link). Notice that 1.8% is smaller than the performance variation from r263227 which is a very innocuous-looking change but caused ~2-3% slowdown for ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and --build-id)"). -- Sean Silva On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I was wanderi...

...34ca5194d5e5e28d760cc8a730a2e1f3b2b6a21f Author: Rafael Espindola <rafael.espindola at gmail.com> Date: Fri Mar 11 12:19:05 2016 +0000 Compute value of local symbol with getVA. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk at 263225 91177308-0d34-0410-b5e6-96231b3b80d8 r263227 ~2-3% slowdown for ScyllaDB commit 6b96b614d9e0232b106165255148af8909607ec1 Author: George Rimar <grimar at accesssoftek.com> Date: Fri Mar 11 12:57:52 2016 +0000 [ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC. git-svn-id: https://llvm.org/svn/llvm-project...

I was wandering how much is the overhead of virtual function calls of TargetInfo member functions. TargetInfo handles platform-specific details, and we have target-specific subclasses of that class. The subclasses override functions defined in TargetInfo. The TargetInfo member functions are called multiple times for each relocation. So the cost of virtual function calls may be non-neglible. That

.... Are you measuring with a build of LLD with LTO+PGO (+ICP+WholeDevirtualization...)? We have compiler technologies to address these problems, I think we'd better leave it to them when they can handle it. -- Mehdi > > Notice that 1.8% is smaller than the performance variation from r263227 which is a very innocuous-looking change but caused ~2-3% slowdown for ScyllaDB (see the thread "LLD performance w.r.t. local symbols (and --build-id)"). > > -- Sean Silva > > On Wed, Mar 30, 2016 at 3:39 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org <mailto:...

...thor: Rafael Espindola <rafael.espindola at gmail.com<mailto:rafael.espindola at gmail.com>> Date: Fri Mar 11 12:19:05 2016 +0000 Compute value of local symbol with getVA. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk at 263225 91177308-0d34-0410-b5e6-96231b3b80d8 r263227 ~2-3% slowdown for ScyllaDB commit 6b96b614d9e0232b106165255148af8909607ec1 Author: George Rimar <grimar at accesssoftek.com<mailto:grimar at accesssoftek.com>> Date: Fri Mar 11 12:57:52 2016 +0000 [ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC. git-...