[llvm-dev] Proposal for address-significance tables for --icf=safe

[Peter Collingbourne via llvm-dev]

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 it
> could be potentially useful for other linkers, for example gold?
>

Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a sequence
of ULEB128-encoded symbol table indexes that are address-significant).

I think it makes sense for this to eventually be part of the generic ABI,
and I will send a proposal to generic-abi. As I mentioned in my reply to
James Knight, I don't think we should block on getting a section number
assignment, but we can at least 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 only works
> with
> > certain languages and is slow due to the need to demangle symbols and
> scan
> > relocations. It's also redundant with the (local_)unnamed_addr analysis
> > already performed by LLVM.
> >
> > I implemented an alternative to this approach in clang and lld. It works
> by
> > adding a section to each object file containing the indexes of the
> symbols
> > which are address-significant (i.e. not (local_)unnamed_addr in IR).
> >
> > I used this implementation to link clang with release+asserts with each
> of
> > --icf={none,safe,all}. The binary sizes were:
> >
> > none: 109407184
> > safe: 108534736 (-0.8%)
> > all: 107281360 (-2%)
> >
> > I measured the object file overhead of these sections in my clang build
> at
> > 0.08%. That's almost nothing, and I think it's small enough that we can
> turn
> > it on by default.
> >
> > I've uploaded a patch series for this feature here:
> > https://github.com/pcc/llvm-project/tree/llvm-addrsig
> > I intend to start sending it for review soon.
> >
> > Thanks,
> > --
> > --
> > Peter
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>



-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180523/a7a7420a/attachment.html>