[PATCH] D17529: ELF: Implement ICF.

[Rui Ueyama via llvm-commits]

By the way, for ICF, I think we eventually want to have the compiler emit a
(cryptographically-safe) hash value for each section to eliminate
byte-by-byte comparison.

That would not only greatly reduce time we spent on ICF but also on
build-id computation. "--build-id" option is casually added to the linker
command line, but that is actually pretty expensive operation. For example,
GNU gold spends about 10% link time just for computing a hash value.

On Tue, Feb 23, 2016 at 3:12 PM, Sean Silva via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

>
>
> On Tue, Feb 23, 2016 at 2:32 PM, Rafael Espíndola <
> llvm-commits at lists.llvm.org> wrote:
>
>> > I think the "take the address" part is the crucial hint. Can't you tell
>> > from the combination of visibility and relocations what functions are
>> > safe to merge? The only tricky part I can imagine is identifying
>> > vtables, as they do not classify as pointer leak.
>>
>> Somewhat. Gold has that on its list of heuristics, but it is pretty
>> nasty. In particular, using files compiled with -fPIC to produce
>> regular executables breaks the heuristic.
>>
>> Lets focus on the non-safe version for now. When time comes I think
>> the correct thing to do is to implement the nop padding as it is
>> always safe and then propose adding a flag to ELF to say that a
>> particular section/symbol doesn't need an unique address.
>>
>
> Yeah. The compiler already knows the this information. No need for the
> linker to bend over backward to try to recover it.
>
> -- Sean Silva
>
>
>>
>> Cheers,
>> Rafael
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160223/0bcc6f30/attachment.html>