<div dir="ltr">Understood - my POV is from trunk. <br><br>If people think it's safer to revert patches for 4.0, I'd suggest reverting everything that was added to value tracking's matchMinMax() since 3.9. That should remove doubt (but miss quite a few min/max improvements).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 27, 2017 at 5:52 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 4:42 PM, Sanjay Patel <<a href="mailto:spatel@rotateright.com">spatel@rotateright.com</a>> wrote:<br>
> This patch targets precisely the patterns that were matched in r286318, so I<br>
> don't see how reverting that would be a better solution. And I was being<br>
> generous by calling the existing code "arbitrary" - those folds were in<br>
> foldICmpUsingKnownBits(), and they have nothing do with known bits. :)<br>
><br>
<br>
</span>This problem seems to manifest only after you added the matchers, right?<br>
So maybe a different solution would be that not matching these<br>
constructs until there are problems surrounding them (as we don't<br>
really know what could be the effect down the road). If you don't want<br>
to do that in trunk and see if things stick together, fair enough, but<br>
I think it's more cautious removing the matchers for 4.0 as they may<br>
expose other problems we'<br>
re not really aware of. Up to you anyway.<br>
<span class=""><br>
> We'd still have the general problem that various parts of the code define<br>
> min/max differently. The bigger solution is to canonicalize min/max harder<br>
> and standardize the min/max definitions, but that's going to take time to<br>
> sort out all the places we have ad hoc min/max checks and then make sure<br>
> that the code still does what was intended (and doesn't induce inf-loop from<br>
> some other transform).<br>
><br>
<br>
</span>Agree. I think this problem should be addressed before adding new<br>
matchers for min/max and not in parallel (or after).<br>
<br>
Thanks,<br>
<br>
--<br>
Davide<br>
</blockquote></div><br></div>