similar to: LLD performance w.r.t. local symbols (and --build-id)

Slowdown by "[ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC.?" looks wierd for me. I do not see any reasons for any impact on perfomance by this change. Good news is that since it was NFC it can easily be reverted. But I think slowdown in results is unrelative with that change and reverting will not give us 2-3% boost back. Best regards, George.

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

On Tue, Feb 28, 2017 at 12:10 PM, Rui Ueyama <ruiu at google.com> wrote: > 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. > You're right,

On Tue, Feb 28, 2017 at 11:39 PM, Rui Ueyama <ruiu at google.com> wrote: > I also did a quick profiling a few months ago and noticed just like you > that scanRelocations consumes a fairly large percentage of overall > execution time. That caught my attention because at the time I was looking > for a place that I can parallelize. > > scanRelocations is not parallelizable

> In conclusion: > Why are people using Git disadvantaged? Short answer: because of git-svn and differences between what is a tag in git and svn. Long answer: git-svn never created proper git tags. Instead, it converted svn tags to branches (because technically branches and tags are same in svn). These branches were orphan and not usable for bunch of things (I believe Takumi can provide a

On Mon, Feb 9, 2015 at 9:47 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hans, > >>> I see a Git branch "release_36", but what has v3.6.0rc2 for a >>> commit-id, can you tags that? >>> No, there are no tags at all @ github. >> >> Anton, is it possible to translate the svn tags to git tags? > In the past we had problems

I believe the relocation stuff that Rafael is currently working on will make this a non-issue (it will make relocation application much friendlier for the CPU). However, even in the 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

On Wed, Mar 30, 2016 at 4:20 PM, Sean Silva <chisophugis at gmail.com> wrote: > I believe the relocation stuff that Rafael is currently working on will > make this a non-issue (it will make relocation application much friendlier > for the CPU). > I don't think Rafael's patch would make this a non-issue. He's making scanRelocs to create data, which would reduce the

Hi, Compiling on PP64/FreeBSd, I get several of these: /usr/home/kparzysz/bld.lv/tools/llvm-mc/Release+Asserts/llvm-mc.o: In function `llvm::formatted_raw_ostream::~formatted_raw_ostream()': llvm-mc.cpp:(.text.startup.main+0xe4): undefined reference to `LLVMInitializeARM64TargetInfo' llvm-mc.cpp:(.text.startup.main+0x154): undefined reference to `LLVMInitializeARM64TargetMC'

To rebuild, it would be enough to remove .git/svn/refs/remotes/git-svn/.rev_map.* My usual way to resync; $ git fetch llvm.org (is remote name) $ git update-ref refs/remotes/git-svn llvm.org/master $ git svn fetch Partial-rebuilding .git/svn/refs/remotes/git-svn/.rev_map.91177308-0d34-0410-b5e6-96231b3b80d8 ... Currently at 124651 = 071d3af0de273b1079d79f7f979264f28d567373 r124653 =

Hi Anton, git-svn got confused at the branch point for the release_31: I see that the current release_31 branch has been created on r155051 as a copy of r155050 from trunk, and r155050 is actually removing an older release_31 branch: Revision 155050 Author: void Date: Wed Apr 18 16:38:33 2012 CDT (11 days, 20 hours ago) Log Message: Removing old release_31 branch for rebranching. This

These numbers were collected on Rafael's clang-fsds test case (however, I removed -O3 and --gc-sections) with a command like: ``` sudo perf record --event=cache-misses --call-graph=dwarf -- /home/sean/pg/llvm/release/bin/ld.lld @response.txt -o /tmp/t --no-threads ``` And then ``` sudo perf report --no-children --sort dso,srcfile ``` One annoying thing about these numbers from perf is that

After updating from trunk today, I am seeing this failure in hwasan: FAIL: HWAddressSanitizer-x86_64 :: TestCases/sizes.cpp (19011 of 49508) ******************** TEST 'HWAddressSanitizer-x86_64 :: TestCases/sizes.cpp' FAILED ******************** <snip> Command Output (stderr): -- + : 'RUN: at line 1' + /build/./bin/clang --driver-mode=g++ -fsanitize=hwaddress -mllvm

Hi ! Our buildbot found this regression while compiling the kernel with clang: A bisection points to 475ac5d302ba84ac13d34a9215c29c1a38ca5690 is the first bad commit commit 475ac5d302ba84ac13d34a9215c29c1a38ca5690 Author: Eric Christopher <echristo at gmail.com> Date: Thu May 15 01:10:50 2014 +0000 Unify command line handling of MCTargetOptions and remove extra options and

FYI, I have been maintaining my own release_31 manually on github.com/chapuni. 2012/5/1 Sebastian Pop <spop at codeaurora.org>: > Hi Anton, > > git-svn got confused at the branch point for the release_31: I see > that the current release_31 branch has been created on r155051 as a > copy of r155050 from trunk, and r155050 is actually removing an older > release_31 branch:

> On Mar 30, 2016, at 4:25 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Mar 30, 2016 at 4:20 PM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote: > I believe the relocation stuff that Rafael is currently working on will make this a non-issue (it will make relocation application much friendlier for the CPU).

We have customers that rely on the symbol information from the "pubnames" section in the DWARF data. Generation of this information was removed in this commit: commit dfa30e1ab243990eda4732a6dffb91e965e7a755 Author: Eric Christopher <echristo at apple.com> Date: Wed Nov 9 05:24:07 2011 +0000 Remove the pubnames section, no one consumes it. git-svn-id:

Hi, git messages for the LLVM source quote the equivalent SVN revisions with a line like this: git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 165785 91177308-0d34-0410-b5e6-96231b3b80d8 But the URL doesn't work; instead we get the following error message: The requested URL /svn/llvm-project/llvm/trunk at 165785 was not found on this server. The tip of the trunk is visible

This commit has added __hwasan_memset to compiler-rt: commit 749bd83b08b7239f5d18c4e3095183919c68eb30 Author: Eugene Leviant <eleviant at accesssoftek.com> Date: Thu Dec 20 09:10:03 2018 +0000 [HWASAN] Add support for memory intrinsics This is patch complements D55117 implementing __hwasan_mem* functions in runtime Differential revision: https://reviews.llvm.org/D55554

On Wed, Mar 30, 2016 at 4:25 PM, Rui Ueyama <ruiu at google.com> wrote: > On Wed, Mar 30, 2016 at 4:20 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> I believe the relocation stuff that Rafael is currently working on will >> make this a non-issue (it will make relocation application much friendlier >> for the CPU). >> > > I don't think