search for: scanreloc

...ave already been scanned. - There is a short term fix, but in the longer term I think that we will want to allow multiple passes of the relocations. - I'd like to know if there are any preferences on a solution. The current thunk implementation scans for and adds Thunks to InputSections within scanRelocations(). At present a Thunk for a RegularSymbol is always added to the InputSection that defines the RegularSymbol. I think that this can cause a problem when the InputSection with the relocation that needs to be indirected via the thunk is processed after the InputSection that the thunk is added t...

...thing called by SymbolTable::addFile) The frontend work seems to be largely dominated by ObjectFile::parse (as you would expect), though there is about 10% of total runtime slipping through the cracks here in various other "frontend" tasks. The backend work is split about evenly between scanRelocations and OutputSection::writeTo. InputSectionBase::relocate is only about 10% of the total runtime (part of OutputSection::writeTo). Some slightly cleaned up `perf report` output with some more details: https://reviews.llvm.org/P7972 So it seems like overall, the profile is basically split 3 way...

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 as-is because it does some global > operations as side effects such as addi...

...nd 000000010dc0 000000000403 R_AARCH64_RELATIV 7a8 Where 0x7a8 (dynamic relocation r_addend) points to a function at .text segment (in this case frame_dummy). I am trying to made this on lld, but current step sequence is: - Write::run \_ Write::createSections \_ Write::scanRelocs \_ Write::addReloc // Dynamic Relocation creation \_ Write::writeSections \_ OutputSectionBase::writeTo \_ InputSection::writeTo \_ InputSection::relocate \_ TargetInfo::relocateOne The problem is only at TargetInfo::relocate the target (aarch64) w...

...hisophugis 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 number of calls to the virtual functions, but it wouldn't be reduced to zero. 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...

...MipsLA25Thunk or something like that. I think you want to create a new type > of thunk for ARM. > > The bug that we sometimes create broken MIPS thunks seems to have introduced > in r265673 which Rafael made. Before that patch, we didn't assume that > section VAs are available in scanRelocs. I think we want to revert that > change (although it cannot simply be reverted because the patch was > submitted in April, and many changes has been made on it since then.) > > Rafael, can you take at that change? > > On Tue, Jun 21, 2016 at 9:38 PM, Peter Smith <peter.smith...

...: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 number of calls to the virtual functions, but it wouldn't be reduced to zero. > > 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...

...> >> 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 number of calls to the > virtual functions, but it wouldn't be reduced to zero. > > 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 >...

...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 number of calls to the >> virtual functions, but it wouldn't be reduced to zero. >> >> However, even in the current scheme, since the target is fixed, all the >>> indirect call sites should be monomorphic and so there shouldn...

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

...at 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 number of calls to the >>> virtual functions, but it wouldn't be reduced to zero. >>> >>> However, even in the current scheme, since the target is fixed, all the >>>> indirect call sites should be monomorphic and so...

...RelaDyn->addReloc(Type, &Sec, Offset, &Sym, Addend, R_ADDEND, Type); + return; + } bool CanWrite = (Sec.Flags & SHF_WRITE) || !Config->ZText; if (CanWrite) { // R_GOT refers to a position in the got, even if the symbol is preemptible. @@ -977,7 +985,7 @@ static void scanReloc(InputSectionBase &Sec, OffsetGetter &GetOffset, RelTy *&I, // all dynamic symbols that can be resolved within the executable will // actually be resolved that way at runtime, because the main exectuable // is always at the beginning of a search list. We can leverage that fact....

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

Hi, I'm in the process of migrating from clang5 to clang10. Unfortunately clang10 introduced a negative performance impact. The cause is an increase of PLT entries from this patch (first released in clang7): https://bugs.llvm.org/show_bug.cgi?id=36370 https://reviews.llvm.org/D43383 If I revert that clang patch locally, the additional PLT entries and the performance impact disappear. This

...This would mean that the final address of each caller and callee could be used, and after thunk creation there would be no further content changes. This would mean: - All code that runs prior to thunk creation may have the offset in the OutputSection altered by the addition of thunks. In particular scanRelocs() calculates the offset in the OutputSection of some relocations. We would need to find alternative ways of handling these cases so that they could either survive thunk creation or be patched up afterwards. - assignAddresses() will need to run at least twice if thunks are created. At least once to...

...orking 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 number of calls to the >>>> virtual functions, but it wouldn't be reduced to zero. >>>> >>>> However, even in the current scheme, since the target is fixed, all the >>>>> indirect call sites should be mon...

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

...;> each caller and callee could be used, and after thunk creation there >> would be no further content changes. This would mean: >> - All code that runs prior to thunk creation may have the offset in >> the OutputSection altered by the addition of thunks. In particular >> scanRelocs() calculates the offset in the OutputSection of some >> relocations. We would need to find alternative ways of handling these >> cases so that they could either survive thunk creation or be patched >> up afterwards. >> - assignAddresses() will need to run at least twice if...

...n we know that a PLT entry will be resolved within the same ELF module, we >>>> can skip PLT access and directly jump to the destination function. >>>> The responsible code that performs PLT->PC relaxation is the "expr = fromPlt(expr);" >>>> line in `scanReloc(...)` >>>> (https://github.com/llvm/llvm-project/blob/master/lld/ELF/Relocations.cpp#L1377) >>>> >>>> Hope that clarifies the situation a bit. >>>> >>>> Best regards, >>>> George | Developer | Access Softek, Inc >>>&...