[llvm-dev] Status of the function merging pass?
Shoaib Meenai via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 31 12:24:21 PST 2019
(Disclaimer: I don’t know anything about MergeFunctions; I’m just assuming functionality from the name)
How does MergeFunctions compare to performing identical code folding (ICF) in the linker?
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org>
Reply-To: Vedant Kumar <vsk at apple.com>
Date: Thursday, January 31, 2019 at 11:52 AM
To: llvm-dev <llvm-dev at lists.llvm.org>
Cc: "nikic at php.net" <nikic at php.net>
Subject: [llvm-dev] Status of the function merging pass?
Hi,
I'm interested in finding ways to reduce code size. LLVM's MergeFunctions pass seems like a promising option, and I'm curious about its status in tree.
Enabling MergeFunctions gives a 1% code size reduction across the entire iOS shared cache (a collection of a few hundred system-critical DSO's). The numbers are even more compelling for Swift code. In fact, the swift compiler enables MergeFunctions by default when optimizing, along with an even more aggressive merging pass which handles equivalence-modulo-constant-uses (https://github.com/apple/swift/blob/master/lib/LLVMPasses/LLVMMergeFunctions.cpp).
Is anyone actively working on enabling MergeFunctions in LLVM's default pipelines? Is there a roadmap for doing so?
ISTM that preventing miscompiles when merging functions is a serious, unsolved problem. I.e., it's hard for the MergeFunctions pass to be *really sure* that two functions are a) really identical and b) safe to merge.
Is there a systematic solution at the IR-level, given that the semantics of IR are subject to change? Is extensive testing the only solution? Or is this intractable, and the only safe approach is to perform merging post-regalloc (or, at some late point when equivalence is easier to determine)?
thanks,
vedant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190131/713359d2/attachment.html>
More information about the llvm-dev
mailing list