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

[Daniel Berlin via llvm-commits]

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>