This is an archive of the discontinued LLVM Phabricator instance.

[ELF] Implement --icf=safe
AbandonedPublic

Authored by MaskRay on May 22 2018, 11:56 PM.

Details

Summary

gold --icf=safe is used in some Android and Chrome builds.

In C++, ctors and dtors are not allowed to be taken addresses. This
property is exploited by gold --icf=safe to fold only ctors and dtors,
and functions whose addresses are not taken (by checking target-specific relocations).

Checking relocation is too hacky and we should avoid that.
This revision implements a weak version of --icf=safe by checking only ctors and dtors. It might be less effective than gold --icf=safe, but would allow Android/Chrome/... builds to pass.

Event Timeline

MaskRay created this revision.May 22 2018, 11:56 PM
MaskRay updated this revision to Diff 148163.May 22 2018, 11:57 PM

CHECK-NEXT:

MaskRay edited the summary of this revision. (Show Details)May 23 2018, 12:14 AM
MaskRay edited the summary of this revision. (Show Details)May 23 2018, 12:24 AM
ruiu added a comment.May 23 2018, 11:59 AM

As you know, I also experimented the same idea to merge ctors/dtors (which I shared with you as https://reviews.llvm.org/D47034), and what I noticed was that the size reduction by this version of safe ICF is negligible. When I link Firefox with my patch, I observed only 0.16% size reduction.

I have another concern about the gold-style safe ICF. Gold's safe ICF is inherently hacky as it depends on heuristics which are not really guaranteed by any compiler or standard, and that's inherently slow because it needs to collect evidences form many places to determine whether a section seems to safe to merge or not. Since Peter now has a proposal of doing it in a better, controlled manner, I personally don't want to add the gold-style safe ICF to lld. Once we add some feature, we can't delete a feature in practice. We'll have to live with it in the foreseeable future. So eventually we'd have two safe ICFs if we add gold's ICF now. I'd like to err on the conservative side to not add a lesser one if some better one is coming.

MaskRay abandoned this revision.May 23 2018, 4:49 PM

I hadn't noticed the better proposal when I sent this one out. I'll abandon this revision