[llvm] r204912 - InstCombine: merge constants in both operands of icmp.

Erik Verbruggen erik.verbruggen at me.com
Fri Mar 28 07:58:49 PDT 2014


I reverted the patch, together with Reid's follow-up patch.

I'm very interested in suggestions on how to fix this "properly" :-)

-- Erik.

On 28 Mar 2014, at 13:54, Erik Verbruggen <erik.verbruggen at me.com> wrote:

> FWIW: patch with "fix" attached.
> 
> I have to say that I don't really see the ordering problem, so could you enlighten me?
> 
> <0001-InstCombine-do-not-merge-icmp-X-C1-C2-when-the-add-h.patch>
> 
> 
> On 27 Mar 2014, at 22:50, Chandler Carruth <chandlerc at google.com> wrote:
> 
>> I would suggest reverting and discussing more.
>> 
>> I'm not really happy with the one-use hack to "fix" this. I think there should be a better way that more directly addresses the problem of extending the liveness of other SSA values, or essentially the canonicalization phase ordering problem that is here.
>> 
>> 
>> On Thu, Mar 27, 2014 at 1:47 PM, Tobias Grosser <tobias at grosser.es> wrote:
>> On 03/27/2014 08:42 PM, Reid Kleckner wrote:
>> On Thu, Mar 27, 2014 at 12:30 PM, Benjamin Kramer <benny.kra at gmail.com>wrote:
>> 
>> 
>> On 27.03.2014, at 20:23, Erik Verbruggen <erikjv at me.com> wrote:
>> 
>> Actually, I'm wondering if it's better to revert my patch (and yours).
>> The "nightly" test-suite pointed out a regression. If you have a tight for
>> loop, like:
>>     for (i = 0; i <= 39; i++)
>>        doSomethingHere;
>> 
>> then before the patch it would be:
>>     %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
>>     %exitcond = icmp eq i64 %indvars.iv.next, 40
>> 
>> while with the patch it's:
>>     %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
>>     %exitcond = icmp eq i64 %indvars.iv, 39
>> 
>> That keeps the "old" %indvars.iv alive. This causes some performance
>> tests to fail, like MultiSource/Benchmarks/MiBench/telecomm-gsm.
>> 
>> I Cc-ed d0k because he did the review, so what do you guys think?
>> 
>> A simple fix would be to check if the add has just one use. I was hoping
>> that this kind of workaround wouldn't be necessary anymore but it looks
>> like we still need it in this case :|
>> 
>> 
>> I'm not really an optimizer person, so whatever works for you guys, revert
>> or fix forward.  I'm mostly concerned with the miscompile, and that has a
>> test case now.  :)
>> 
>> Yes, I am getting spammed by the LNT buildbots the whole day. Would you guys mind to either commit a fix now or just revert until the issue has been solved.
>> 
>> Thank you,
>> Tobias
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> _______________________________________________
> 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/20140328/99f1e86c/attachment.html>


More information about the llvm-commits mailing list