[PATCH] D17529: ELF: Implement ICF.
Rui Ueyama via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 23 15:25:58 PST 2016
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
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
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits