search for: icf

...l is considered address significant? This would sidestep the problem of keeping the symbol table indices in sync. It would be pessimistic for local symbols if the input SHT_ADDRSIG sections were combined by e.g. "ld -r" but in my experience this should not have too much of an impact on --icf. Might be worth considering in the short term whilst you work on getting gabi acceptance. On Tue, May 22, 2018 at 11:06 PM, Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > Context: ld.gold has an --icf=safe flag which is intended to apply ICF &g...

Hi all, Context: ld.gold has an --icf=safe flag which is intended to apply ICF only to sections which can be safely merged according to the guarantees provided by the language. It works using a set of heuristics (symbol name matching and relocation scanning). That's not only imprecise but it only works with certain languages and is...

....google.com/forum/#!forum/generic-abi as it could be potentially useful for other linkers, for example gold? Happy to help out with reviews. Peter On 22 May 2018 at 23:06, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi all, > > Context: ld.gold has an --icf=safe flag which is intended to apply ICF only > to sections which can be safely merged according to the guarantees provided > by the language. It works using a set of heuristics (symbol name matching > and relocation scanning). That's not only imprecise but it only works with > cert...

...incorporate any design feedback from that proposal. Peter > Happy to help out with reviews. > > Peter > > > On 22 May 2018 at 23:06, Peter Collingbourne via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > > > Context: ld.gold has an --icf=safe flag which is intended to apply ICF > only > > to sections which can be safely merged according to the guarantees > provided > > by the language. It works using a set of heuristics (symbol name matching > > and relocation scanning). That's not only imprecise but it...

...y to help out with reviews. >>> >>> Peter >>> >>> >>> On 22 May 2018 at 23:06, Peter Collingbourne via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> > Hi all, >>> > >>> > Context: ld.gold has an --icf=safe flag which is intended to apply ICF >>> only >>> > to sections which can be safely merged according to the guarantees >>> provided >>> > by the language. It works using a set of heuristics (symbol name >>> matching >>> > and reloca...

...>> >>>> Peter >>>> >>>> >>>> On 22 May 2018 at 23:06, Peter Collingbourne via llvm-dev >>>> <llvm-dev at lists.llvm.org> wrote: >>>> > Hi all, >>>> > >>>> > Context: ld.gold has an --icf=safe flag which is intended to apply >>>> ICF only >>>> > to sections which can be safely merged according to the guarantees >>>> provided >>>> > by the language. It works using a set of heuristics (symbol name >>>> matching >>...

...; Peter > > > >> Happy to help out with reviews. >> >> Peter >> >> >> On 22 May 2018 at 23:06, Peter Collingbourne via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > Hi all, >> > >> > Context: ld.gold has an --icf=safe flag which is intended to apply ICF >> only >> > to sections which can be safely merged according to the guarantees >> provided >> > by the language. It works using a set of heuristics (symbol name >> matching >> > and relocation scanning). That'...

...y to help out with reviews. >>> >>> Peter >>> >>> >>> On 22 May 2018 at 23:06, Peter Collingbourne via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> > Hi all, >>> > >>> > Context: ld.gold has an --icf=safe flag which is intended to apply ICF >>> only >>> > to sections which can be safely merged according to the guarantees >>> provided >>> > by the language. It works using a set of heuristics (symbol name >>> matching >>> > and reloca...

On Tue, May 22, 2018 at 6:06 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > Context: ld.gold has an --icf=safe flag which is intended to apply ICF > only to sections which can be safely merged according to the guarantees > provided by the language. It works using a set of heuristics (symbol name > matching and relocation scanning). That's not only imprecise but it only > works with cert...

...>> >>>> Peter >>>> >>>> >>>> On 22 May 2018 at 23:06, Peter Collingbourne via llvm-dev >>>> <llvm-dev at lists.llvm.org> wrote: >>>> > Hi all, >>>> > >>>> > Context: ld.gold has an --icf=safe flag which is intended to apply >>>> ICF only >>>> > to sections which can be safely merged according to the guarantees >>>> provided >>>> > by the language. It works using a set of heuristics (symbol name >>>> matching >>...

...ter >>>>> >>>>> >>>>> On 22 May 2018 at 23:06, Peter Collingbourne via llvm-dev >>>>> <llvm-dev at lists.llvm.org> wrote: >>>>> > Hi all, >>>>> > >>>>> > Context: ld.gold has an --icf=safe flag which is intended to apply >>>>> ICF only >>>>> > to sections which can be safely merged according to the guarantees >>>>> provided >>>>> > by the language. It works using a set of heuristics (symbol name >>>>&g...

...flag set, it propagates the >liveness >of this section to the parent. This allows the garbage collector to also >remove >children sections if dependent parent sections are marked to be removed. > >I found a similar code already inside lld. There is a special case for ARM. >When ICF being enabled, this live propagation of linked sections is already >performed for ARM targets in ICF::run(). However, I think this makes sense >also for other targets. > >I am new to lld and may not know all implications of the SHF_LINK_ORDER flag >or what implications my proposed ch...

...f the feature. Do you mind if you ask you to describe your plan if you have a use case in mind? On Tue, Feb 6, 2018 at 4:27 AM, James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > Hi, > > > > We’d like to propose an extension to both the map file and the > print-gc/icf-sections output. This extension would be to report the pieces > of .eh_frame and SHF_MERGE sections in these files somehow. Since all (or > at least the majority) of the contents of these sections in the output come > from inputs, it would be beneficial in trying to associate the output &g...

Hi, We’d like to propose an extension to both the map file and the print-gc/icf-sections output. This extension would be to report the pieces of .eh_frame and SHF_MERGE sections in these files somehow. Since all (or at least the majority) of the contents of these sections in the output come from inputs, it would be beneficial in trying to associate the output contents with whe...

...out invoking Propeller. Function sections has found uses after it > > was invented like Identical Code Folding. > > > > I'm not sure that function sections are entirely an apt comparison > here for a few reasons: > > - function sections mostly gave an easy way to do ICF - using MIR or > LLVM IR are also fairly effective means as is just using the linker to > I did not mean to suggest we should do folding with basic block sections and I am aware of the issues, though I am not ruling out the possibility. We had briefly brainstormed this. AFAICT, Function Sec...

...it > >> > was invented like Identical Code Folding. > >> > > >> > >> I'm not sure that function sections are entirely an apt comparison > >> here for a few reasons: > >> > >> - function sections mostly gave an easy way to do ICF - using MIR or > >> LLVM IR are also fairly effective means as is just using the linker to > > > > > > I did not mean to suggest we should do folding with basic block sections > and I am aware of the issues, though I am not ruling out the possibility. > We had brief...

On 23 May 2018 at 23:07, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: >> >> On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> >> wrote: >>> >>> Hello, >>> >>> I think that the approach of using a

...e Folding. > >> >> > > >> >> > >> >> I'm not sure that function sections are entirely an apt comparison > >> >> here for a few reasons: > >> >> > >> >> - function sections mostly gave an easy way to do ICF - using MIR or > >> >> LLVM IR are also fairly effective means as is just using the linker > to > >> > > >> > > >> > I did not mean to suggest we should do folding with basic block > sections and I am aware of the issues, though I am not ruli...

...luding comments and blank lines. IMHO the code is simple and easy to read. (This is of course not a third-party opinion, so you are welcomed to read the code. You can skip Windows-specific code to get a whole picture.) Advanced features It supported dead-stripping from day one. I added preliminary ICF (Identical COMDAT Folding) support yesterday. Implementing that was basically just a one day task. Peter Collingbourne (pcc) added an experimental LTO support to the linker. The code for LTO seems to naturally fit to the other pieces of code. Flexibility When I first set the architecture, I was wo...

...gt;>> >> >> >>> >> >> I'm not sure that function sections are entirely an apt comparison >>> >> >> here for a few reasons: >>> >> >> >>> >> >> - function sections mostly gave an easy way to do ICF - using MIR >>> or >>> >> >> LLVM IR are also fairly effective means as is just using the >>> linker to >>> >> > >>> >> > >>> >> > I did not mean to suggest we should do folding with basic block >>&gt...