<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><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 href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>><br>
> To: "John Regehr" <<a href="mailto:regehr@cs.utah.edu">regehr@cs.utah.edu</a>><br>
> Cc: <a 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 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 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 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 href="mailto:LLVMdev@cs.uiuc.edu">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 class="im HOEnZb">> _______________________________________________<br>
> LLVM Developers mailing list<br>
</span><div class="HOEnZb"><div class="h5">> <a href="mailto:LLVMdev@cs.uiuc.edu">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 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>