[PATCH][InstCombiner] Expose opportunities to merge subtract and comparison

[Quentin Colombet]

Hi,

Here is a patch to expose more subtract and comparison fusion opportunities.
I am not sure the approach I have taken is the best one, so let me know if you think I should proceed differently.

Thanks for the feedbacks/reviews.

** Context **

Several architectures use the same instruction to perform both a comparison and a subtract. Our current instruction selection framework does not allow to consider different basic blocks to expose such fusion opportunities. As it is, these instructions are “merged” by CSE in the MI IR level.


** Proposed Solution **

To increase the likelihood of CSE to apply in such situation, the proposed patch reorders the operands of the comparison so that they matches the order of the most frequent subtract.
E.g.,

icmp A, B
…
sub B, A

B is used as the first argument of a sub with A. The comparison should match this for CSE to come into play.

This is done during instcombine. 


** Motivating Example **

The attached scratch.cc shows two different functions that do exactly the same thing (the order of the operands in the ‘if’ and the condition are inversed) but produces different code quality.
Function PASS has its comparison and subtract merged, function FAIL does not.

To reproduce:
clang -O3 -arch x86_64 scratch.cc -S -o -


** Notes **

1. Why LLVM IR for this “low-level” optimization?
As already stated, several architectures expose such opportunities, therefore, I thought it may be best to do it as a target independent optimization. LLVM IR makes more sense for that. Doing this at MI IR level would require several additional target hooks or a specific pass for each target.

2. What about the canonical form?
The optimization is only performed when both operands have the same complexity.
We might want to break the complexity assumption (operands ordered from most to less complex) but I am not sure it will bring new opportunities.
Thus, assuming we want to do that transformation at LLVM IR level, is it desirable to break that assumption and if yes, in which pass?

Cheers,
-Quentin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130827/748927ec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scratch.cc
Type: application/octet-stream
Size: 446 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130827/748927ec/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130827/748927ec/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: InstCombineCSE.svndiff
Type: application/octet-stream
Size: 4906 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130827/748927ec/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130827/748927ec/attachment-0002.html>