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

Thu May 31 18:05:56 PDT 2018

On Thu, May 31, 2018 at 5:29 PM Peter Collingbourne <peter at pcc.me.uk> wrote:

> 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 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 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.
>>>>>
>>>>
>>>> I've sent the proposal:
>>>> https://groups.google.com/forum/#!topic/generic-abi/MPr8TVtnVn4
>>>>
>>>
>>> Based on feedback from the generic-abi thread I looked at the object
>>> file size and link time impact of a few other representations for the
>>> address-significance table. My results are here:
>>> https://groups.google.com/d/msg/generic-abi/MPr8TVtnVn4/30Z0_KHMAQAJ
>>>
>>> One of the proposals (a compressed array of symbol attributes) is
>>> slightly more expensive than what I originally proposed (+0.03% object file
>>> size, +1% link time) but it would allow for future expansion and therefore
>>> seems more appropriate for the gABI. That's not really a concern for us
>>> though since the initial implementation will use a platform-specific
>>> section number, and we can always switch to the gABI representation at the
>>> same time as we adopt the gABI section numbers. There's also the
>>> possibility that we will end up doing something completely different in the
>>> gABI.
>>>
>>> Does anyone have a strong opinion that we should do something more
>>> aligned with the gABI? If not, I'll start upstreaming my original proposal.
>>>
>>>
>> I suppose it depends on whether or not you're going to be the one to
>> reconcile your current implementation and that one in the future or if
>> it'll wait for someone else?
>>
>
> I'm happy to volunteer to work on that if the proposal ever gets accepted
> into the gABI and I'm still working on LLVM at that time.
>
>
Then I think whatever is easier for you. I'd have a vague preference of
something closer to the gABI proposal in case you're hit by a bus, but
understand that you've already got the current code written as well.

-eric

> Peter
>
>
>> -eric
>>
>>
>>> Peter
>>>
>>>>
>>>> Peter
>>>>
>>>>>
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Peter
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> 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/20180531/190ad439/attachment.html>