<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 22, 2015 at 10:54 AM, escha <span dir="ltr"><<a href="mailto:escha@apple.com" target="_blank">escha@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jul 22, 2015, at 10:15 AM, John Regehr <<a href="mailto:regehr@cs.utah.edu">regehr@cs.utah.edu</a>> wrote:<br>
><br>
> We (the folks working on Souper) would appreciate any feedback on 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=Z1yyJi4Gm0nRzGaRiiU5o2ptVNf9oqnrIO3ffbFbnS0&s=3E3vPueUVY7xEJht2hbnyR352XYpYpI94E-b00hM15E&e=" rel="noreferrer" target="_blank">http://blog.regehr.org/extra_files/souper-jul-15.html</a><br>
><br>
</span><span class="">> My impression is that while there's clearly plenty of material in here that doesn't want to get implemented in an opt pass, there are 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=Z1yyJi4Gm0nRzGaRiiU5o2ptVNf9oqnrIO3ffbFbnS0&s=YRNrO-LNum0vp4AbhcBPlpiHvEd_cIFIGb99s-FzJHg&e=" rel="noreferrer" target="_blank">http://blog.regehr.org/archives/1252</a><br>
><br>
</span>> Thanks!<br>
><br>
> John<br>
<br>
I was reading about these; it looks really interesting! One thing that I worry about is that we want to make sure not to IR-transform into “weird constructs” that might be very suboptimal on certain targets (and hard or impossible to invert later); e.g. you noted that selects had cost 3 in your model, but I work on a GPU where select_cc (fcmp/icmp + select) has cost 1. Doing sneaky bit math to avoid a select might be good in some cases, but not others. Maybe it could use target hooks of some sort so it only does transformations that makes sense given a certain cost model?<br></blockquote><div><br></div><div>Even on x86, materializing i1's residing in the condition flags is a pain (e.g. to sext) but CMOVcc based on them is easy.</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>
—escha<br>
<span class="">_______________________________________________<br>
LLVM Developers mailing list<br>
</span><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>
</blockquote></div><br></div></div>