<div dir="ltr">This patch targets precisely the patterns that were matched in r286318, so I don't see how reverting that would be a better solution. And I was being generous by calling the existing code "arbitrary" - those folds were in foldICmpUsingKnownBits(), and they have nothing do with known bits. :)<br><br>We'd still have the general problem that various parts of the code define min/max differently. The bigger solution is to canonicalize min/max harder and standardize the min/max definitions, but that's going to take time to sort out all the places we have ad hoc min/max checks and then make sure that the code still does what was intended (and doesn't induce inf-loop from some other transform).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 27, 2017 at 4:43 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jan 27, 2017 at 3:26 PM, Sanjay Patel via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> Author: spatel<br>
> Date: Fri Jan 27 17:26:27 2017<br>
> New Revision: 293345<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=293345&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project?rev=293345&view=rev</a><br>
> Log:<br>
> [InstCombine] move icmp transforms that might be recognized as min/max and inf-loop (PR31751)<br>
><br>
> This is a minimal patch to avoid the infinite loop in:<br>
> <a href="https://llvm.org/bugs/show_bug.cgi?id=31751" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_<wbr>bug.cgi?id=31751</a><br>
><br>
> But the general problem is bigger: we're not canonicalizing all of the min/max forms reported<br>
> by value tracking's matchSelectPattern(), and we don't define min/max consistently. Some code<br>
> uses matchSelectPattern(), other code uses matchers like m_Umax, and others have their own<br>
> inline definitions which may be subtly different from any of the above.<br>
><br>
> The reason that the test cases in this patch need a cast op to trigger is because we don't<br>
> (yet) canonicalize all min/max forms based on matchSelectPattern() in<br>
> canonicalizeMinMaxWithConstant<wbr>(), but we do make min/max+cast transforms based on<br>
> matchSelectPattern() in visitSelectInst().<br>
><br>
> The location of the icmp transforms that trigger the inf-loop seems arbitrary at best, so<br>
> I'm moving those behind the min/max fence in visitICmpInst() as the quick fix.<br>
><br>
<br>
</span>Ehm.. this workaround seems a little fragile. Maybe reverting the<br>
original commit which introduced this behavior would be a better thing<br>
for now? <a href="https://reviews.llvm.org/rL286318" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>rL286318</a> (i.e. until we have an idea<br>
on how to fix this properly)<br>
</blockquote></div><br></div>