<div dir="ltr">Hi everyone,<div><br></div><div>I would like to discuss a possible road map for having a more powerful function merging optimization.</div><div><br></div><div>At the moment, the function merging optimization in LLVM is focused on merging completely equivalent functions. On the other end of this spectrum, for my last paper in CGO'19, "Function Merging by Sequence Alignment", we proposed a function merging optimization that is able to merge virtually any two functions.<br></div><div><br></div><div>Just as a reference, I've made available the prototype of my optimization in this Github repo:</div><div><a href="https://github.com/rcorcs/fmsa">https://github.com/rcorcs/fmsa</a><br></div><div>In this repo, I have a unified infrastructure that I'm using to perform both my Function Merging by Sequence Alignment (FMSA) and also an improved version of the Branch Fusion that was first proposed to reduce divergence in GPUs. The idea here is to show that this "code merger" infrastructure based on sequence alignment doesn't need to be used only by the Function Merger.</div><div><br></div><div>FMSA, as an optimization, is composed of two key components: (1) the merge operation of two arbitrary functions (which should always produce a merged function, but not necessarily always smaller than the original ones); (2) the ranking mechanism used for efficient exploration of the search space.</div><div><br></div><div>One option would be to have a road map similar to the following:</div><div>  - Add the general merge operation as a utility function.</div><div>  - Combine this merge operation with the divergence analysis to create the branch fusion optimization. This would allow the community to validate and get familiar with the merge operation.</div><div>  - Create FMSA with an exploration mechanism (either the ranking-based one, a hash-based one, or a combination of both). The way I see it, FMSA could be used with -Oz and the existing "identical"-only merger could be used with -Os.</div><div><br></div><div>An alternative option would be to slowly enable the current function merger to handle some differences in the code. Each one of the new features could be added in two steps, first creating a patch that enables the FunctionComparator to handle it and then, in a second patch, enable the actual MergeFunctions <span class="inbox-inbox-gr_ inbox-inbox-gr_543 inbox-inbox-gr-alert inbox-inbox-gr_gramm inbox-inbox-gr_inline_cards inbox-inbox-gr_run_anim inbox-inbox-Grammar inbox-inbox-only-ins inbox-inbox-replaceWithoutSep" id="inbox-inbox-543" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat">pass</span> to also handle it.</div><div><br></div><div>The key features to enable are:</div><div>  - Handle different operands by either reordering the operands or inserting select instructions.</div><div>  - Handle different return types with a union-like approach.</div><div>  - Handle different list of parameters.</div><div>  - Handle differences within basic blocks.<br></div><div>  - Handle differences in the CFG.</div><div>The way I see it, as we enable more and more of these features, we would get closer and closer to the FMSA merge operation and exploration. However, the process of integrating the sequence alignment strategy into the more structural FunctionComparator is not yet clear to me.</div><div><br></div><div>A very simple patch that I am preparing in this direction is to enable the reordering of operands in equivalent commutative instructions.</div><div><br></div><div>I would really appreciate some feedback.<br></div><div><br></div><div>Reference:</div><div>"Function Merging by Sequence Alignment",</div><div>Rodrigo Rocha, Pavlos Petoumenos, Zheng Wang, Murray Cole, Hugh Leather<br></div><div><a href="https://doi.org/10.1109/CGO.2019.8661174">https://doi.org/10.1109/CGO.2019.8661174</a><br></div><div><br></div><div>Many thanks,</div><div>Rodrigo Rocha</div><div><br></div></div>