search for: mergeinputsections

Hi, Does lld support linker relaxation that may shrink code size? As far as I see lld seems to assume that the content of input sections to be fixed other than patching up relocations, but I believe some targets may benefit the extra optimization opportunity with relaxation. Specifically, I'm currently working on adding support for RISC-V in lld, and RISC-V heavily relies on linker relaxation

...s been shortened from 18 bytes to 12 bytes due to the other changes. On Tue, Jul 11, 2017 at 1:59 PM, Peter Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello, > > To the best of my knowledge I think the closest analogue is something > like the Synthetic EHFrame and MergeInputSections, not strictly code > relaxation, but these do involve changes in size of sections. > > Can I ask you a quick question? In many architectures not all > pc-relative offsets are exposed to the linker as relocations so it > isn't safe to change the sizes of sections in arbitrary pla...

On Fri, Nov 6, 2020 at 2:32 AM James Henderson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Alexey, > > On Thu, 5 Nov 2020 at 21:02, Alexey Lapshin <avl.lapshin at gmail.com> wrote: >> >> Hi James, >> >> On 05.11.2020 17:59, James Henderson wrote: >> >> (Resending with history trimmed to avoid it getting stuck in moderator

...t;> > >> On Tue, Jul 11, 2017 at 1:59 PM, Peter Smith via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hello, >>> >>> To the best of my knowledge I think the closest analogue is something >>> like the Synthetic EHFrame and MergeInputSections, not strictly code >>> relaxation, but these do involve changes in size of sections. >>> >>> Can I ask you a quick question? In many architectures not all >>> pc-relative offsets are exposed to the linker as relocations so it >>> isn't safe to chang...

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 James, On 05.11.2020 17:59, James Henderson wrote: > (Resending with history trimmed to avoid it getting stuck in moderator > queue). > > Hi Alexey, > > Just an update - I identified the cause of the "Generated debug info > is broken" error message when I tried to build things locally: the > `outStreamer` instance is initialised with the host Triple,

Hi Rafael, On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: > However, do we need to start with instrumentation? The original paper > uses sampling with good results and current intel cpus can record every > branch in a program. > > I would propose starting with just an lld patch that reads the call > graph from a file. The format would be very similar to

I've recently implemented profile guided section layout in llvm + lld using the Call-Chain Clustering (C³) heuristic from https://research.fb.com/wp-content/uploads/2017/01/cgo2017-hfsort-final1.pdf . In the programs I've tested it on I've gotten from 0% to 5% performance improvement over standard PGO with zero cases of slowdowns and up to 15% reduction in ITLB misses. There are

A rebased version of the lld patch is attached. Cheers, Rafael On 31 July 2017 at 15:11, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > Tobias Edler von Koch <tobias at codeaurora.org> writes: > >> Hi Rafael, >> >> On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: >>> However, do we need to start with