<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 11/11/2017 12:44 PM, Amara Emerson
wrote:<br>
</div>
<blockquote
cite="mid:1784BCDB-531F-47A1-A664-240F1038E407@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Nov 10, 2017, at 10:04 PM, Aditya Nandakumar
<<a moz-do-not-send="true"
href="mailto:proaditya@gmail.com" class="">proaditya@gmail.com</a>>
wrote:</div>
<div class="">
<blockquote type="cite" class="" style="font-family:
SFHello-Regular; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space:
normal; widows: auto; word-spacing: 0px;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px;">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><br
class="">
The current DAGCombine, being constructed on top of
SDAG, has a kind of built-in CSE and automatic DCE.
How will things change, if they'll change, in this new
model?<br class="">
</div>
</div>
</blockquote>
<div class="" style="font-family: SFHello-Regular;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">Hi Hal,</div>
<div class="" style="font-family: SFHello-Regular;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;"><br class="">
</div>
<div class="" style="font-family: SFHello-Regular;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">I suspect one option is
to have a separate CSE pass, and the backends get to
choose where exactly they plug in their pipeline. I think
DCE should be part of the combine pass (and the legalizer
is about to start doing that as well).</div>
</div>
</blockquote>
For SSA form MIR there’s already the MachineCSE pass. How
important the CSE/DCE is at the combine stage I don’t know. As
an approximation perhaps we can get an idea by disabling the
behavior in the DAGCombiner and seeing the effects.</div>
</blockquote>
<br>
My impression is that the automated CSE and DCE is very important to
the current implementation. There's a lot of code that depends on
his happening in order to have the expected effects. Otherwise, the
use-count checks won't do the right thing (because the old unused
uses of things won't immediately go away).<br>
<br>
I'm not entirely sure you can just turn off the uniquing in SDAG and
get a sensible result.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:1784BCDB-531F-47A1-A664-240F1038E407@apple.com"
type="cite">
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="">On Nov 10, 2017, at 9:54 PM, Daniel Sanders <<a
moz-do-not-send="true"
href="mailto:daniel_l_sanders@apple.com" class="">daniel_l_sanders@apple.com</a>>
wrote:</div>
<div class="">
<div class="" style="font-family: SFHello-Regular;">
<div class="">
<div class=""><br class="">
</div>
My thinking on this is that (with a few exceptions that
I'll get to), combine and select are basically the same
thing. You match some MIR, and replace it with other
MIR. The main difference being that combine doesn't have
to constrain to register classes (unless it wants to)
while select does.</div>
<div class=""><br class="">
</div>
<div class="">With that in mind, I was thinking that it
makes sense to put a lot of effort into the optimization
of the tablegen-erated selection table (as has been
started in Quentin's recent patch) and then re-use it
for combines too. We'll need to be careful how we define
GlobalISel's counterpart to SelectionDAG patterns to
make it expressive enough to support combines but that's
essentially a second frontend (the other being the
SelectionDAG importer) on a common backend</div>
</div>
</div>
</blockquote>
<div class="">Agreed that combine and selection are similar
processes. It sounds like this is something we should look at
prototyping.</div>
<div class=""><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div class="" style="font-family: SFHello-Regular;">
<div class=""><br class="">
</div>
<div class="">Req 2 becomes simple to implement in this
approach. You can either use the existing feature-bits
mechanism to enable/disable combine rules as a group, or
add an equivalent mechanism in tablegen to decide
whether a rule makes it into the emitted table or not
and have multiple tables which you can run/not-run at
will. With the new coverage feedback mechanism, we could
potentially organize our tables semi-automatically by
highlighting combine rules that never or rarely fire in
a particular pass.</div>
<div class=""><br class="">
</div>
<div class="">One feature I think we ought to have that
isn't on the requirements list already, is that I think
we should have a means to support rules with more than
one match root. For example (using SelectionDAG
patterns):</div>
<div class=""> (set $dst1:GPR32, (i32 (load $ptr:GPR64)))</div>
<div class=""> (set $dst2:GPR32, (i32 (load (add
$ptr:GPR64 4))))</div>
<div class="">into:</div>
<div class=""> (set $tmp:GPR64, (v2s32 (load
$ptr:GPR64)))</div>
<div class=""> (set $dst1, (extractelt $tmp:GPR64, 0))</div>
<div class=""> (set $dst2, (extractelt $tmp:GPR64, 1))</div>
<div class="">Or something along those lines (such as
fusing div/mod together). The combiner should be smart
enough to make the root the $ptr, and follow the use of
$ptr into the load/add, then follow the def to the 4.</div>
</div>
</div>
</blockquote>
This seems like a nice feature, but I wonder about the impact
this will have on the speed of the matching algorithm. I don’t
know enough about it to say though. IMO complex features can be
done in C++ code if they’re uncommon, in preference for fast
handling of the common cases. Maybe a few more use cases are
needed.</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Amara</div>
</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>