[llvm-dev] Status of the function merging pass?

[Teresa Johnson via llvm-dev]

On Fri, Feb 1, 2019 at 10:58 AM Vedant Kumar <vsk at apple.com> wrote:

> On Jan 31, 2019, at 4:40 PM, Aditya K <hiraditya at msn.com> wrote:
>
>
> Hi Nikita,
>
> Glad to hear that Rust code can benefit a lot from this.
>
> I have put patches to enable merge-similar functions with thinLTO.
> https://reviews.llvm.org/D52896 etc. <https://reviews.llvm.org/D52896>
>
>
I had some comments on several of these, but I don't think they were
addressed yet? One of my meta comments was that it would be better to have
the patches be standalone increments on top of each other (they seemed to
be split up somewhat arbitrarily when I looked before - maybe this has been
fixed?), and link them in phab as parent/child revisions (so you can get a
stack of them displayed in phab to see the relationships).
Thanks,
Teresa

>
> This is more powerful than existing merge-functions pass and all we need
> to do is port these patches to trunk llvm. I'd be happy to help with this
> effort.
>
>
> At the risk of straying too far off-topic: I think this patch is
> interesting, but would need help to understand it better. Would you mind
> starting a new thread about it? Specifically, I’d like to know what the
> marginal benefit is of factoring out dissimilar instructions, versus simply
> factoring out dissimilar constants. Presumably there’s a compile-time vs.
> performance vs. code size tradeoff. I think this is worth digging into
> because equivalence-module-constant-uses merging was sufficient for Swift.
>
> vedant
>
>
>
>
> -Aditya
>
>
> ------------------------------
> *From:* Nikita Popov <nikita.ppv at gmail.com>
> *Sent:* Thursday, January 31, 2019 3:46 PM
> *To:* Vedant Kumar
> *Cc:* llvm-dev; Reid Kleckner; Aditya K; whitequark at whitequark.org;
> Teresa Johnson; Duncan P. N. Exon Smith; Jessica Paquette
> *Subject:* Re: Status of the function merging pass?
>
> On Thu, Jan 31, 2019 at 8:52 PM Vedant Kumar <vsk at apple.com> wrote:
>
> 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)?
>
>
> In Rust we've been running with MergeFunctions enabled by default for a
> while now, and have recently also enabled the use of aliases instead of
> thunks. Apart from some initial bugs we didn't encounter any significant
> issues (one minor issue with NVPTX not supporting aliases and having CC
> restrictions).
>
> As Rust tends to be quite heavy on monomorphization, MergeFuncs can give
> significant binary size reductions. I don't have any comprehensive numbers,
> but from checking this on a pet project just now, it reduces final artifact
> size by 13% and I've seen some similar numbers in the ~10% range quoted
> before.
>
> So, at least for Rust's use case this pass seems to be both quite robust
> and useful :)
>
> Regards,
> Nikita
>
>
>

-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190201/f659cb29/attachment.html>