similar to: lld dynamic relocation creation issue

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

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

Hi, There are more than one MIPS relocations which need GOT entry creation. Let's consider two of them R_MIPS_GOT16 and R_MIPS_CALL16 [1]. R_MIPS_GOT16 is applicable to local and external symbols and performs a different calculation in each cases [2]. R_MIPS_CALL16 is applicable to external symbols only and a linker should show an error if it finds R_MIPS_CALL16 with a local target. Now LLD

> On May 17, 2016, at 1:33 AM, Shi, Steven via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > Let me ask a LTO simple question again. For the llvm LTO example in the link:http://llvm.org/docs/LinkTimeOptimization.html <http://llvm.org/docs/LinkTimeOptimization.html>, I use below build commands to generate three different optimization level binary: -O0, -O1, -O2.

Hi all, I've run into problems compiling the llvm-gcc frontend on x86_64. Is this not supported, or am I making an error somewhere? The procedure I followed was: 1. Download LLVM 2.0 source as a tarball (from a few days ago, during the testing phase). 2. Download the llvm-gcc4 source today, as a tarball. 3. Extract both. 4. Configure LLVM as: ../src/configure --prefix=`pwd`../install

Hi Warren, You have the -m32 flag set, but it's still giving you this: > Warning: Generation of 64-bit code for a 32-bit processor requested. > Warning: 64-bit processors all have at least SSE2. But are you sure you want to compile the LLVM-GCC source? You should use the binaries unless absolutely necessary. -bw On May 24, 2007, at 10:34 PM, Warren Armstrong wrote: > Hi all,

Hi Umesh, Thank you for the suggestion. I can use the "Brute force method " to narrow down the LTO wrong instructions here and there, but I still don't know why these wrong instructions are generated, and how to let Clang LTO don't generate those wrong instructions. I suspect the wrong code is caused by some LTO wrong optimization pass, so I hope to disable all optimizations in

Here's a working testcase: ; ModuleID = '/tmp/crtbegin.bc' target datalayout = "E-p:32:32:128-i1:8:128-i8:8:128-i16:16:128-i32:32:128-i64:32:128-f32:32:128-f64:64:128-v64:64:64-v128:128:128-a0:0:128-s0:128:128" target triple = "spu" @__dso_handle = hidden global i8* null, align 16 ; <i8**> [#uses=0] @__CTOR_LIST__ = internal global [1 x void

I've been working on supporting ARM/Thumb interworking thunks in LLD and have encountered a limitation that I think it is worth bringing up in a wider context. This is all LLD specific, apologies if I've abused llvm-dev here. TL;DR summary: - Thunks in lld may not work if they are added to InputSections that have already been scanned. - There is a short term fix, but in the longer term I

Hi Warren, you can try to configure with the following export CFLAGS="-m64" export LDFLAGS="-L/usr/lib64" LLVM: ../src/configure --prefix=`pwd`../install --enable-optimized --enable-jit --enable-targets=host-only make LLVM-GCC: ../llvm-gcc4-2.0.source/configure --prefix=`pwd`../install --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ --enable-languages=c,c++

Hello guys, Today I tried to find the amount of LLD(elf) code covered by our test cases. So my aim was to run the LLD tests we have (run check-lld task) and find out which code was executed/covered and which was not. I used the approach from the next article to do that: http://logan.tw/posts/2015/04/28/check-code-coverage-with-clang-and-lcov/#create-a-wrapper-script-for-lcov In short, it is

Hello, We've recently started using ifuncs in the x86(_64) FreeBSD kernel. Currently lld will emit a PLT entry for each ifunc, so ifunc calls are more expensive that those of regular functions. In our kernel, this overhead isn't really necessary: if lld instead emits PC-relative relocations for each ifunc call site, where each relocation references a symbol of type GNU_IFUNC, then during

Thanks a lot for doing this. Having it automated an in a bot would be really nice. Cheers, Rafael George Rimar <grimar at accesssoftek.com> writes: > Hello guys, > > Today I tried to find the amount of LLD(elf) code covered by our test cases. So my aim was to run the LLD tests we have (run check-lld task) and find out which code was executed/covered and which was not. > >

​Hi all, > I feel it might be confusing to have a CHECK becomes effectively a CHECK-NOT, > especially if the RUN line is far from the CHECK line (which is often the case when > a single RUN line drives several groups of CHECK directives (e.g. code generation > tested for several functions for a specific feature, like PIC). You also loose control > on where the NOT should be:

Hi, I am working on support R_MIPS_HI16 / R_MIPS_LO16 in the new LLD and have a couple of questions. == Q1 In case of MIPS O32 ABI we have to find a matching R_MIPS_LO16 relocation to calculate R_MIPS_HI16 one because R_MIPS_HI16 uses combined addend (AHI << 16) + (short)ALO where AHI is original R_MIPS_HI16 addend and ALO is addend of the matching R_MIPS_LO16 relocation [1]. There are two

Tim, Thanks for the explanation. "it tells the linker to insert the address of date when converting this .o file into a final executable." Which utility do you use to convert .o to .elf and insert the address of 'date'? llvm-objcopy? ________________________________ From: Tim Northover <t.p.northover at gmail.com> Sent: Wednesday, March 13, 2019 3:20 AM To: Josh Sharp Cc:

I'm about to start working on range extension thunks in lld. This is an attempt to summarize the approach I'd like to take and what the impact will be on lld outside of thunks. I'm interested if anyone has any constraints the approach will break, alternative suggestions, or is working on something I'll need to take account of? I expect range extension thunks to be important for

On 11/15/20 12:21 PM, John Fawcett wrote: > I'm using tika-server.jar installed as a service yup. same here. atm, listening on localhost, with Dovecot -> Tika direct, no proxy. similarly fragile under load. throwing ~10 messages with .5-5MB attachments at it at once causes all sorts of complaints. one at a time seems OK ... > Dovecot currently implements separate integrations,

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