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

[Quentin Colombet]

Thanks Evan!

Committed in r190352.

-Quentin

On Sep 9, 2013, at 10:58 AM, Evan Cheng <evan.cheng at apple.com> wrote:

> Yes, I'm fine with the patch.
> 
> Evan
> 
> On Sep 3, 2013, at 9:40 AM, Quentin Colombet <qcolombet at apple.com> wrote:
> 
>> Ping?
>> 
>> Evan, does it mean it looks good for you?
>> 
>> -Quentin
>> 
>> On Aug 27, 2013, at 1:58 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>> 
>>> 
>>> On Aug 27, 2013, at 1:41 PM, Quentin Colombet <qcolombet at apple.com> wrote:
>>> 
>>>> 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.
>>> 
>>> Actually ignore me. After reading your original email more carefully I think instcombine is ok.
>>> 
>>> Evan
>>> 
>>>> 
>>>> Thanks Evan.
>>>> 
>>>> -Quentin
>>>>> 
>>>>> 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/20130909/3eda3b60/attachment.html>