[llvm-commits] [Patch] Optimize away a cmp instruction on X86

[Manman Ren]

For the cases handled by this patch, the code produces CMOV ISD node, but even without this added section, the default is to produce a CMOV ISD node.
So in terms of whether to use CMOV for SELECT, I am following the default implementation.

This patch only handles sub+cmp for SELECT, a better implementation is to perform this optimization in peephole, then X86 will be handled in the same way as ARM.

It will be great if we can implement this in a target-independent way, but I don't think we can represent dependency on flags in a target-independent way?
If we remove 'cmp', we need to represent that 'sub' will update EFLAGS and there is a dependency from 'sub' to the SELECT due to EFLAGS.

Thanks,
Manman

On May 29, 2012, at 12:42 PM, Chandler Carruth wrote:

> On Tue, May 29, 2012 at 12:27 PM, Manman Ren <mren at apple.com> wrote:
> 
> 
> This patch is to replace sub+cmp with X86ISD::SUB when possible, it does not touch the decision of whether we should use 'cmp+jmp' or 'cmov'.
> 
> Hmm, the oddity is that you do directly produce the CMOV ISD node. It looks like this will only fire on 'sub+cmp+cmov', not 'sub+cmp+jmp'. I suppose this is an artifact of this transform happening deep inside of the x86 backend, and so the decision of whether or not to use a branch vs. cmov has long since happened? Making sure I understand what you're doing here...
> 
> If I've understood this correctly, wouldn't that mean that the same logic will be needed again for code that emits the 'sub+cmp+jmp'? Is that already handled somewhere?
> 
> All in all, I'm agreeing with a comment on this bit of code: should this really be so specific? I'm seeing the possibility for a third copy of the core functionality here, it would be great if there were a way to put this into the dag-combine step, maybe even the target-independent dag-combine? Haven't thought much about the feasibility of that though...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120529/fb953bf4/attachment.html>