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

Quentin Colombet qcolombet at apple.com
Tue Aug 27 13:41:58 PDT 2013

On Aug 27, 2013, at 1:30 PM, Evan Cheng <evan.cheng at apple.com> wrote:

> On Aug 27, 2013, at 12:34 PM, Quentin Colombet <qcolombet at apple.com> wrote:
>> ** 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.
> I'm not sure about this. Instcombine's primary responsibility is canonicalization. Is it possible for this to pessimize code on certain targets?
Not that I am aware of, but I guess it might be possible.
Do you think we should somehow guard this transformation with a target hook?

> Have you considered doing this at codegenprep time?
No, I have not, and I think you are right, it would make more sense there.

Thanks Evan.

> Evan
>> 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
>> <scratch.cc>
>> <InstCombineCSE.svndiff>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

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

More information about the llvm-commits mailing list