<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 07/22/2015 01:49 PM, Philip Reames
wrote:<br>
</div>
<blockquote cite="mid:55B001DA.9020305@philipreames.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<br>
<div class="moz-cite-prefix">On 07/22/2015 01:28 PM, Sean Silva
wrote:<br>
</div>
<blockquote
cite="mid:CAHnXoamcSppg6RJZb3DzPnyrFQjRAAjEKJMU4OzWvXPA5wFW1g@mail.gmail.com"
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 moz-do-not-send="true"
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>
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>
</blockquote>
I took a shot at implementing this and it looks like instcombine is
actually canonicalizing in the opposite direction. All truncs to i1
are being converted to an and/cmp pattern. Anyone know why this
is? I expected that as a lowering in selectiondag, but doing in
InstCombine seems too early.... I guess I can see an argument that
we're not actually loosing any information (i.e. ComputeKnownBits
will handle the and/cmp just fine), but this still seems a bit
surprising. Anyone have thoughts here?<br>
<br>
Anyways, at least those half dozen items from the list appear to be
WONTFIX. :)<br>
<blockquote cite="mid:55B001DA.9020305@philipreames.com" type="cite">
<br>
<br>
<br>
<blockquote
cite="mid:CAHnXoamcSppg6RJZb3DzPnyrFQjRAAjEKJMU4OzWvXPA5wFW1g@mail.gmail.com"
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"> <br>
-Hal<br>
<span class=""><br>
----- Original Message -----<br>
> From: "Sean Silva" <<a moz-do-not-send="true"
href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>><br>
> To: "John Regehr" <<a moz-do-not-send="true"
href="mailto:regehr@cs.utah.edu">regehr@cs.utah.edu</a>><br>
> Cc: <a moz-do-not-send="true"
href="mailto:llvmdev@cs.uiuc.edu">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 moz-do-not-send="true"
href="mailto:regehr@cs.utah.edu">regehr@cs.utah.edu</a>
><br>
<span class="im HOEnZb">> wrote:<br>
><br>
><br>
> We (the folks working on Souper) would appreciate
any feedback on<br>
> these IR-level superoptimizer results:<br>
><br>
> <a moz-do-not-send="true"
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 class="im HOEnZb">> 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>
> <a moz-do-not-send="true"
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="im HOEnZb">> Thanks!<br>
><br>
> John<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
</span><span class="im HOEnZb">> <a
moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" rel="noreferrer"
target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a moz-do-not-send="true"
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 class="im HOEnZb">>
_______________________________________________<br>
> LLVM Developers mailing list<br>
</span>
<div class="HOEnZb">
<div class="h5">> <a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" rel="noreferrer"
target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a moz-do-not-send="true"
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 class="HOEnZb"><font color="#888888">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span></blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>