<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 22, 2015 at 1:49 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<br>
<div>On 07/22/2015 01:28 PM, Sean Silva
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jul 22, 2015 at 12:54 PM, Hal
Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One
thing that is important to consider is where in the
pipeline these kinds of optimizations fit. We normally try
to put the IR into a canonical simplified form in the
mid-level optimizer. This form is supposed to be whatever
is most useful for exposing other optimizations, and for
lowering, but only in a generic sense. We do have some
optimizations near the end of our pipeline (vectorization,
partial unrolling, etc.) that consider target-specific
properties, but only because the alternative is doing
those loop optimizations after instruction selection.<br>
<br>
Considering ILP and other pipeline-level costs are
something we generally consider only in the SelectionDAG
and after. If these are IR optimizations, then I'm not
sure that considering ILP, etc. is the right metric -- so
long as the transformations are sufficiently reversible to
allow of efficient lowering afterward.<br>
</blockquote>
<div><br>
</div>
<div>Agreed. It might just be that these initial results are
from the "burn-in" specifically targeting short simple
sequences, but most of the transformations in the link
seem to be things that, if applicable, we would want to do
in the backend instead of in the middle-end.</div>
</div>
</div>
</div>
</blockquote></span>
Looking through the items, I see a number which are suitable for mid
level canonicalization. For example, the two for converting
and/cmps into truncs seem like good candidates. We need to make
sure to apply judgement here, but not *all* of these are backend
specific. <br></div></blockquote><div><br></div><div>Hence "most". From the blog post it seems like this batch is deliberately obtained by running Souper on particularly short sequences; I'm looking forward to seeing what it does with longer sequences, especially ones containing "phis and path conditions".</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>-- Sean Silva</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
-Hal<br>
<span><br>
----- Original Message -----<br>
> From: "Sean Silva" <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>><br>
> To: "John Regehr" <<a href="mailto:regehr@cs.utah.edu" target="_blank">regehr@cs.utah.edu</a>><br>
> Cc: <a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a><br>
> Sent: Wednesday, July 22, 2015 2:35:51 PM<br>
> Subject: Re: [LLVMdev] some superoptimizer results<br>
><br>
><br>
><br>
> Are you taking into account critical path length?
Because e.g. for:<br>
><br>
><br>
><br>
> %0:i64 = var<br>
> %1:i1 = slt 18446744073709551615:i64, %0<br>
> %2:i64 = subnsw 0:i64, %0<br>
> %3:i64 = select %1, %0, %2<br>
> infer %3<br>
> %4:i64 = ashr %0, 63:i64<br>
> %5:i64 = add %0, %4<br>
> %6:i64 = xor %5, %4<br>
> result %6<br>
><br>
><br>
> In the former case, the cmp and sub are
independent, so can be<br>
> executed in parallel, while in the latter case all
3 instructions<br>
> are dependent. So the former case can execute in 2
cycles while the<br>
> latter takes 3. Modern OoO chips do in fact exploit
this kind of<br>
> thing.<br>
><br>
><br>
> -- Sean Silva<br>
><br>
><br>
><br>
><br>
</span>> On Wed, Jul 22, 2015 at 10:15 AM, John Regehr
< <a href="mailto:regehr@cs.utah.edu" target="_blank">regehr@cs.utah.edu</a>
><br>
</div></div><span><div><div class="h5">> wrote:<br>
><br>
><br>
> We (the folks working on Souper) would appreciate
any feedback on<br>
> these IR-level superoptimizer results:<br>
><br></div></div>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.regehr.org_extra-5Ffiles_souper-2Djul-2D15.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=Zws35DV5cT6VNt0_Wc8MbZqd8-UXh4q602LshCf-frE&s=2cBkApfDIxWcm7AqVD7-qdjeHG3okw8lDLBn_URJO2s&e=" rel="noreferrer" target="_blank">http://blog.regehr.org/extra_files/souper-jul-15.html</a><br>
><br>
</span><span><span class="">> My impression is that
while there's clearly plenty of material in<br>
> here that doesn't want to get implemented in an opt
pass, there are<br>
> a number of gems hiding in there that are worth
implementing.<br>
><br>
> Blog post containing additional explanation and
caveats is here:<br>
><br></span>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.regehr.org_archives_1252&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=Zws35DV5cT6VNt0_Wc8MbZqd8-UXh4q602LshCf-frE&s=Ek-DIAbJ7gqXWn_mfOpgfQE3i2dh1D_5peAOqtO1oYc&e=" rel="noreferrer" target="_blank">http://blog.regehr.org/archives/1252</a><br>
><br>
</span><span class=""><span>> Thanks!<br>
><br>
> John<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
</span><span>> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
><br>
</span><span>>
_______________________________________________<br>
> LLVM Developers mailing list<br>
</span>
<div>
<div>> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
</div>
</div>
<span><font color="#888888">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span></span></blockquote>
</div>
<br>
</div>
</div><span class="">
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</span></blockquote>
<br>
</div>
</blockquote></div><br></div></div>