similar to: LLD: time to enable --threads by default

Interesting. Might be worth giving a try again to the idea of creating the file in anonymous memory and using a write to output it. Cheers, Rafael On 23 November 2016 at 02:41, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Wed, Nov 16, 2016 at 12:44 PM, Rui Ueyama via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> LLD supports

SHA1 in LLVM is *very* naive, any improvement is welcome there! It think Amaury pointed it originally and he had an alternative implementation IIRC. — Mehdi > On Nov 16, 2016, at 3:58 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > By the way, while running benchmark, I found that our SHA1 function seems much slower than the one in gold. gold slowed down by

The current implementation was “copy/pasted” from somewhere (it was explicitly public domain). > On Nov 16, 2016, at 4:05 PM, Rui Ueyama <ruiu at google.com> wrote: > > Can we just copy-and-paste optimized code from somewhere? > > On Wed, Nov 16, 2016 at 4:03 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > SHA1 in LLVM is

On 16 November 2016 at 15:52, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I will do a quick benchmark run. On a mac pro (running linux) the results I got with all cores available: firefox master 7.146418217 patch 5.304271767 1.34729488437x faster firefox-gc master 7.316743822 patch 5.46436812 1.33899174824x faster chromium master 4.265597914 patch

On Thu, Nov 17, 2016 at 7:34 PM, Rui Ueyama <ruiu at google.com> wrote: > On Thu, Nov 17, 2016 at 6:30 PM, Davide Italiano <davide at freebsd.org> wrote: >> >> On Thu, Nov 17, 2016 at 1:20 PM, Rafael Espíndola via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> >> >> Thank you for the explanation! That makes sense. >>

On Thu, Nov 17, 2016 at 1:20 PM, Rafael Espíndola via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Thank you for the explanation! That makes sense. >> >> Unlike ThinLTO, each thread in LLD consumes very small amount of memory >> (probably just a few megabytes), so that's not a problem for me. At the >> final stage of linking, we spawn threads to

On Thu, Nov 17, 2016 at 9:50 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Nov 17, 2016, at 9:41 AM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On Thu, Nov 17, 2016 at 6:12 AM, Teresa Johnson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Thu, Nov 17, 2016 at 4:11 AM, Rafael Espíndola

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

I'd like to make LLD embed version information so that we can determine if an executable was created by LLD and if that's the case which version of LLD. ld.bfd doesn't seem to embed any information, so we cannot tell whether an executable was linked by ld.bfd or not easily. ld.gold embeds a string "GNU gold <version>" as ".note.gnu.gold-version" section

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Rui Ueyama" <ruiu at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, October 18, 2016 10:22:00 PM > Subject: Re: [llvm-dev] Embedding LLD version to executables > > > > On Oct 18, 2016, at 6:44

----- Original Message ----- > From: "Mehdi Amini" <mehdi.amini at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Rui Ueyama" > <ruiu at google.com> > Sent: Tuesday, October 18, 2016 10:38:57 PM > Subject: Re: [llvm-dev] Embedding LLD version to executables >

On Tue, Oct 18, 2016 at 8:22 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Oct 18, 2016, at 6:44 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I'd like to make LLD embed version information so that we can determine > if an executable was created by LLD and if that's the case which version of > LLD. >

> Le 3 oct. 2017 à 00:09, Rui Ueyama <ruiu at google.com> a écrit : > > I read through the binutils mailing list thread, but I couldn't find the exact reason why making --hash-style=gnu default except MIPS wasn't a good idea.Do you mind if I ask you to explain it again for me? > > Since lld is a new linker, we could make a bit more radical change than GNU ld can do,

Hi, > Scenario 1: you added -fuse-ld=lld to your command line, but you are suspecting that the option is ignored. Currently, it's actually surprisingly hard to tell if an output was created by LLD. Can't you use -v to see what linker the compiler driver invoked? On Wed, Oct 19, 2016 at 4:41 AM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, Oct 18,

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

I personally haven't tried gdb_index, and I don't know the quality of the produced index. Most of the code was written by George. One thing I noticed about the feature (and filed as http://bugs.llvm.org/show_bug.cgi?id=32228) is that our gdb_index feature is much slower than the gold. Apparently there's room for improvement. On Thu, Mar 16, 2017 at 8:35 AM, David Blaikie <dblaikie

What program did you use to test the feature, and what was missing information? I'd like to file that as a bug so that we can fix this later. On Thu, Mar 16, 2017 at 2:34 PM, David Blaikie <dblaikie at gmail.com> wrote: > FWIW - selfhosting I did find that GDB wasn't able to find the source code > for some functions when using LLD's gdb_index, so I've switched back to

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,

Rafael, You seems to be the person who added --start-lib and --end-lib to gold (*1), so I think you are the best person to ask about it. :) What is the intended use case of the options? Do you think we should support that in LLD? If we want to support that, then I think we can think of two implementation strategies: - Link object files between --start-lib and --end-lib normally and garbage

On Sat, Mar 14, 2015 at 2:52 AM, Nick Kledzik <kledzik at apple.com> wrote: > Rui, > > Thanks for this write up and the work you are doing to improve performance. > A couple of thoughts: > > * In the old days, linking was I/O bound so the linker run tended to be the > same speed as cat’ing all the input files together. Now that spinning disks > are less common, I/O