<div dir="ltr">Reassociate very explicitly doesn't handle i1 at all. But even if it did, the processing for OR doesn't look at its arguments other than finding duplicates and direct inverses. But it won't look through the and to find an inverse.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div>
<br><div class="gmail_quote">On Fri, Jul 14, 2017 at 2:03 PM, Sanjay Patel <span dir="ltr"><<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">That's a good point. The factorization / reassociation in instcombine is just too limited I think. This raises another pair of questions though:<br><br>1. Why doesn't -reassociate catch this either? <br>2. And if we teach reassociate to match this, can we remove some redundant functionality from instcombine?<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 14, 2017 at 12:54 PM, Craig Topper via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Going back to the original problem. Why shouldn't SimplifyUsingDistributiveLaws handle both these cases?<div><br></div><div>For the bitwise test case if you distribute you get</div><div>(~A | A) & (B | A) </div><div><br></div><div>The left side of that simplifies to all 1s which is the identify value for and. So even though the right side doesn't simplify it's a win.</div></div><div class="gmail_extra"><span class="m_4353625140670307770HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_4353625140670307770m_-8068793719721580929gmail_signature" data-smartmail="gmail_signature">~Craig</div></div>
<br></font></span><div class="gmail_quote"><div><div class="m_4353625140670307770h5">On Fri, Jul 14, 2017 at 11:46 AM, Hal Finkel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_4353625140670307770h5">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="m_4353625140670307770m_-8068793719721580929h5">
<p><br>
</p>
<div class="m_4353625140670307770m_-8068793719721580929m_7260588922776647906moz-cite-prefix">On 07/14/2017 01:38 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div class="m_4353625140670307770m_-8068793719721580929m_7260588922776647906h5"><br>
</div>
</div>
Not sure about this last part. It is really going to
require work by us to rewrite things. :-) In the mean
time, I think we should go ahead with this.</div>
</blockquote>
<div><br>
</div>
<div>FWIW: My problem is, when put in this framework, we
will repeatedly make this same decision, this same way,
again and again, and never actually get even started on
fixing it :)</div>
<div><br>
</div>
<div>IE "it's just another small patch!"</div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
You're correct. However, as I'm sure you're aware, developer time is
not directly transferable in a way that makes any other decision
optimal. It's not like blocking all improvements to InstCombine will
cause a movement to appear to rewrite InstCombine. It will only
cause a shrink in the pool of developers with recent experience
working on InstCombine (and a lot of out-of-tree patches). Frankly,
we don't even have a concrete plan for how we'd do this, or even a
target design, and that's the first item on the critical path to a
rewrite. We should start an RFC and iterate on this until we have a
concrete plan and migration plan.<span><br>
<br>
-Hal<br>
<br>
<pre class="m_4353625140670307770m_-8068793719721580929m_7260588922776647906moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</span></div>
<br></div></div><span>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>