<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 07/13/2017 06:40 PM, Daniel Berlin
via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTUcH-uo3hZZHyx-3n2ZfBCAYu0CfdO+KYYQf9cwgVj8Tw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">Ah yes, it can only return one instruction and you
need two.
<div><br>
<div>
<div>NewGVN could still handle it if instsimplify was
changed to return the right binary operators because it
has infrastructure that can handle insertion.<br>
</div>
<div>(it would need a little work).</div>
<div><br>
</div>
<div><br>
</div>
<div>(At this point, InstCombine seems to have become worse
to me than GCC's combining infrastructure, so i'd really
like to see if we can stop putting things there.
Otherwise, we just go farther down the path of 'let's
just make everything one big graph rewrite)</div>
</div>
</div>
</div>
</blockquote>
<br>
Perhaps something of a digression:<br>
<br>
My general impression is that if InstCombine were actually doing a
principled graph rewrite, then we wouldn't have these problems. The
problem we have, however, is that we have phase-ordering problems
(even within the fixed-point iteration scheme): Patterns being
matched depend on a canonical form, instructions nearly matching
those patterns might be created, and then suboptimally consumed
(i.e. further transformed), before being subject to the
canonicalizing transformation(s) that would make the better pattern
actually match.<br>
<br>
Except for TableGen'ing the whole thing, and making an actual graph
automaton to match the patterns, it's not clear to me how to
efficiently fix this. In the mean time, what we've been doing in
practice, is that we have InstCombine patterns depend on canonical
forms, until we hit some phase-ordering problem, and then we extend
the pattern in question to match some non-canonical forms. We might
do this here as well (if that's the problem here), but at some point
I suspect we'll end up redoing everything.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAF4BwTUcH-uo3hZZHyx-3n2ZfBCAYu0CfdO+KYYQf9cwgVj8Tw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
</div>
</blockquote>
<blockquote
cite="mid:CAF4BwTUcH-uo3hZZHyx-3n2ZfBCAYu0CfdO+KYYQf9cwgVj8Tw@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Jul 13, 2017 at 4:37 PM, Sanjay
Patel <span dir="ltr"><<a moz-do-not-send="true"
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">
<div>
<div>This can't be an instsimplify though? The values we
want in these cases do not exist already:<span
class=""><br>
%res = or i8 %b, %a<br>
</span> %res = or i1 %cmp, %c<br>
</div>
<br>
</div>
<br>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Jul 13, 2017 at 5:10
PM, Daniel Berlin <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:dberlin@dberlin.org"
target="_blank">dberlin@dberlin.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"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div class="m_3138728761059436495h5">On
Thu, Jul 13, 2017 at 2:12 PM, Sanjay
Patel <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:spatel@rotateright.com"
target="_blank">spatel@rotateright.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>We have several
optimizations in InstCombine
for bitwise logic ops
(and/or/xor) that fail to
handle compare patterns with
the equivalent bitwise
logic. Example:<br>
<br>
define i8 @or_and_not(i8 %a,
i8 %b) {<br>
%nota = xor i8 %a, -1<br>
%and = and i8 %nota, %b<br>
%res = or i8 %and, %a<br>
ret i8 %res<br>
}<br>
<br>
define i1
@or_and_cmp_not(i32 %a, i32
%b, i1 %c) {<br>
%cmp = icmp sgt i32 %a, %b<br>
%cmp_inv = icmp sle i32
%a, %b ; this is 'not' of
%cmp<br>
%and = and i1 %c, %cmp_inv<br>
%res = or i1 %cmp, %and<br>
ret i1 %res<br>
}<br>
<br>
$ ./opt -instcombine
hidden_not.ll -S<br>
<br>
define i8 @or_and_not(i8 %a,
i8 %b) {<br>
%res = or i8 %b, %a<br>
ret i8 %res<br>
}<br>
<br>
define i1
@or_and_cmp_not(i32 %a, i32
%b, i1 %c) {<br>
%cmp = icmp sgt i32 %a, %b<br>
%cmp_inv = icmp sle i32
%a, %b<br>
%and = and i1 %cmp_inv, %c<br>
%res = or i1 %cmp, %and<br>
ret i1 %res<br>
}<br>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>------------------------------<wbr>------------------------------<wbr>---------<br>
</div>
<br>
Would adding to the existing
InstCombine logic folds to
handle this kind of pattern be
a welcome enhancement? I don't
know if it's possible to make
the matchers handle this case
without adding a new matcher.
Eg:<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
</div>
<div>I would rather see this added to
instsimplify than instcombine.</div>
<div>If you do that, GVN/et all will get
this already.</div>
<div><br>
</div>
<div>This probably does require a special
matcher though:</div>
<div><br>
</div>
<div><br>
We have:</div>
<div> if (m_c_And(m_Cmp(Pred, m_Value(),
m_Value()),<br>
</div>
<div>
<div> m_Cmp(Pred, m_Value(),
m_Value()))</div>
<div><br>
</div>
<div>and you really want:</div>
<div>
<div> if (m_c_And(m_Cmp(Pred, m_Value(),
m_Value()),</div>
<div>
m_Cmp(m_Opposite(Pred), m_Value(),
m_Value()))</div>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>