[LLVMdev] some superoptimizer results (original) (raw)

Sean Silva chisophugis at gmail.com
Wed Jul 22 12:24:35 PDT 2015

On Wed, Jul 22, 2015 at 10:54 AM, escha <escha at apple.com> wrote:

> On Jul 22, 2015, at 10:15 AM, John Regehr <regehr at cs.utah.edu> wrote: > > We (the folks working on Souper) would appreciate any feedback on these IR-level superoptimizer results: > > http://blog.regehr.org/extrafiles/souper-jul-15.html > > 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. > > Blog post containing additional explanation and caveats is here: > > http://blog.regehr.org/archives/1252 > > Thanks! > > John 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 selectcc (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?

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.

-- Sean Silva

—escha

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150722/d651128b/attachment.html>

More information about the llvm-dev mailing list