[PATCH] D59442: Enable Operand Reordering for Commutative Instructions in the FunctionComparator/MergeFunctions

Rodrigo Caetano Rocha via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 19 12:04:04 PDT 2019


rcorcs added a comment.

I understand your point of having a light-weight function merging (FM) to leave always on to reduce code-size/compilation-time.
I agree that perhaps we could have a parametrized merger that enables/disables more powerful comparisons.
That's why I also suggested that a more powerful merger (like my FM by Sequence Alignment) could be only enabled for heavier code-size optimizations (like -Oz) and have a light-weight FM always enabled (or enabled for most of the optimization settings).

You're right about the general problem being NP, but we can do similar tricks to what SLP does, for example.
In SLP, we are also constantly fighting this trade-off between having a better way of identifying isomorphism and compilation-time.
SLP is also based on finding isomorphic graphs (mostly trees), and they also handle operand reordering for commutative operations. In particular, in the function buildTree_rec when SLP is handling binary operations, which is done by the function reorderInputsAccordingToOpcode.
In this patch, I'm kind of borrowing that from SLP.

Regarding the 15% overhead of my FMSA, that is true for my prototype implementation, but I believe that this number can be reduced significantly.
For example, in this paper, we're still doing a lot of wasteful merges (80+%) that we throw away because we always try to merge with the best candidate from the ranking mechanism.
But in most cases, even the top candidate is very dissimilar from the current function being considered, so that we could just avoid trying to merge them.
However, we didn't try to improve that for this paper. But we could have a way for quickly discarding bad candidates, similar to how the ranking itself works.
This, among other things, would definitely reduce the 15% average overhead.

I will look into the canonicalization pass.
I also need to read the discussions, that you shared with me in the mailing list, in more detail. But I'm aware of the MergeSimilarFunctions work, as it is the state-of-the-art that I use for comparison in my paper.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59442/new/

https://reviews.llvm.org/D59442





More information about the llvm-commits mailing list