[PATCH] D22051: MergeSimilarFunctions: a code size pass to merge functions with small differences

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 7 17:10:31 PDT 2016

On Fri, Jul 8, 2016 at 8:38 AM, Tobias Edler von Koch via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> tobiasvk added a comment.
> In http://reviews.llvm.org/D22051#476003, @jfb wrote:
> > Could you detail how this is different from MergeFunc, and what it would
> take to add the new capabilities to MergeFunc instead of duplicating?
> The main difference is that the in-tree MergeFunctions can only merge
> identical functions (modulo pointer types) whereas MergeSimilarFunctions is
> also capable of merging sets of functions that are merely similar, i.e.
> have some differences in their instructions.

Two thoughts after staring at it:

1. If you were to form SESE/etc regions and process them in topo order, you
could actually do even better than you do now.   You would be able to
validly say "the first X regions of this function are the same". You
currently do this in some cases, but you could do it in more :)
2. You could integrate most of what you are doing with mergefuncs with a
bit of work.

This expands the scope of the optimization significantly.
> As to whether this could be integrated into the in-tree MergeFunctions...
> Well, this started off as a patch to MergeFunctions back in 2013. However,
> the in-tree MergeFunctions has undergone significant architectural changes
> since then; it now uses a total ordering of functions to speed up merging.
> This is great if you only want to merge identical functions, but it doesn't
> work for merging of similar functions.

This is not correct.
You could use simhash, for example, or any thing that will give you actual
similarity metrics in addition to total ordering.

> So it really depends on what your optimization goal is. If you want to
> eliminate duplicates quickly, the in-tree MergeFunctions is great. In our
> experience, however, the main benefit comes from being able to deal with
> those small differences here and there that arise e.g. from template
> instantiations or 'copy-paste-and-hack'.
> http://reviews.llvm.org/D22051
> _______________________________________________
> 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/20160708/4490fa41/attachment.html>

More information about the llvm-commits mailing list