search for: icfed

Displaying 20 results from an estimated 138 matches for "icfed".

Did you mean: iced
2018 May 31
0
Proposal for address-significance tables for --icf=safe
Hi Peter, This is a great proposal, thanks!. If you were worried about making the abi change have you thought about just going for an array of symbol names or hashes of symbol names where any matching symbol 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
2018 May 22
7
Proposal for address-significance tables for --icf=safe
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 slow due to the need to demangle symbols and scan
2018 May 23
0
Proposal for address-significance tables for --icf=safe
Hello, I think that the approach of using a section to record address significance is a good one. I'm guessing it will have its own section type and format? If it does would it make sense to try and submit this to the GABI https://groups.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
2018 May 23
4
Proposal for address-significance tables for --icf=safe
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 section to record address > significance is a good one. I'm guessing it will have its own section > type and format? If it does would it make sense to try and submit this > to the GABI https://groups.google.com/forum/#!forum/generic-abi as
2018 May 24
2
Proposal for address-significance tables for --icf=safe
Hi Peter, Thanks for doing this! On Wed, May 23, 2018 at 3:07 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> 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,
2018 May 24
0
Proposal for address-significance tables for --icf=safe
On Thu, May 24, 2018 at 10:24 AM, Eric Christopher <echristo at gmail.com> wrote: > Hi Peter, > > Thanks for doing this! > > On Wed, May 23, 2018 at 3:07 PM Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >>
2018 May 23
0
Proposal for address-significance tables for --icf=safe
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 section to record address >> significance is a good one. I'm guessing it will have its own section >> type and format? If
2018 Jun 01
2
Proposal for address-significance tables for --icf=safe
On Wed, May 23, 2018 at 3:07 PM, 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
2018 May 23
0
Proposal for address-significance tables for --icf=safe
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).
2018 Jun 01
0
Proposal for address-significance tables for --icf=safe
On Thu, May 31, 2018 at 5:06 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, May 23, 2018 at 3:07 PM, 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
2018 Jun 01
1
Proposal for address-significance tables for --icf=safe
On Thu, May 31, 2018 at 5:13 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 31, 2018 at 5:06 PM Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Wed, May 23, 2018 at 3:07 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Wed, May 23, 2018 at
2018 Jan 29
0
[lld] Garbage collection of linked sections with the SHF_LINK_ORDER flag
>Hi folks, > >Our LLVM compiler creates a special debug section, which depends on a >certain >text section. This debug section is created with the SHF_LINK_ORDER >flag, and >sh_link field in the section header points to the correct section. > >When linking the program with the linker flag '-gc-sections', lld can >garbage- >collect unused sections. In my
2018 Feb 06
0
[RFC] Add mergeable and eh_frame section pieces to map files and --print-gc/icf-sections reports
It seems that showing eh_frame section pieces in the map file is useful, but I wonder what would be a concrete use case of 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
2018 Feb 06
3
[RFC] Add mergeable and eh_frame section pieces to map files and --print-gc/icf-sections reports
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 where they came from,
2019 Sep 28
2
[RFC] Propeller: A frame work for Post Link Optimizations
On Fri, Sep 27, 2019 at 10:36 PM Eric Christopher <echristo at gmail.com> wrote: > On Fri, Sep 27, 2019 at 2:08 PM Sriraman Tallam via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Sep 27, 2019 at 1:16 PM Eli Friedman <efriedma at quicinc.com> > wrote: > > > > > > > -----Original Message----- > > > > From:
2019 Sep 30
2
[RFC] Propeller: A frame work for Post Link Optimizations
On Mon, Sep 30, 2019 at 12:26 PM Eric Christopher <echristo at gmail.com> wrote: > On Sat, Sep 28, 2019 at 8:25 AM Sriraman Tallam <tmsriram at google.com> > wrote: > > > > > > > > On Fri, Sep 27, 2019 at 10:36 PM Eric Christopher <echristo at gmail.com> > wrote: > >> > >> On Fri, Sep 27, 2019 at 2:08 PM Sriraman Tallam via
2018 May 24
1
Proposal for address-significance tables for --icf=safe
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
2019 Sep 30
2
[RFC] Propeller: A frame work for Post Link Optimizations
On Mon, Sep 30, 2019 at 1:27 PM Eric Christopher <echristo at gmail.com> wrote: > On Mon, Sep 30, 2019 at 12:31 PM Sriraman Tallam <tmsriram at google.com> > wrote: > > > > > > > > On Mon, Sep 30, 2019 at 12:26 PM Eric Christopher <echristo at gmail.com> > wrote: > >> > >> On Sat, Sep 28, 2019 at 8:25 AM Sriraman Tallam
2015 Jun 24
2
[LLVMdev] LLD COFF status
I've been working on the new LLD COFF linker for 1.5 months so far (including history of my personal repository), and I feel like I should post an update on that matter as a followup to the previous discussion thread. In short, it's doing very well. Completeness It was able to link itself from the first day when the first patch was landed. Since then, I fixed bugs and added more
2019 Sep 30
2
[RFC] Propeller: A frame work for Post Link Optimizations
I guess Eric means full program optimization/cross module optimization using MIR. This is in theory workable in full LTO style, but not in ThinLTO style which works on summary data. As we have discussed, eliminating monolithic style optimization is the key design goal. This was also briefly discussed in one of the previous replies I sent. There are other benefits of doing this in linker such