
Superoptimizing LLVM (2014) [video] - pmalynin
https://www.youtube.com/watch?v=Ux0YnVEaI6A
======
cperciva
_engineering fast, effective and correct optimizations for LLVM is
challenging_

Indeed, just a few days ago I reported a miscompilation bug in the LLVM
optimizer...
[https://llvm.org/bugs/show_bug.cgi?id=27190](https://llvm.org/bugs/show_bug.cgi?id=27190)

------
davidrusu
Seems like work has died down a bit on the Souper repo[0], last commit was in
January.

Anyone know what the current state of super optimization compilers is?

[0] [https://github.com/google/souper](https://github.com/google/souper)

~~~
regehr
It's definitely still an active project, but I'm on sabbatical this academic
year and have had much less time than usual for my regular research. I'll be
getting back to it in June. Also, Raimondas Sasnauskas, who implemented the
instruction synthesizer, finished his postdoc position and moved on.

In any case, there's been a lot of progress since I did that UW talk, for
example here are some early synthesis results:

[http://blog.regehr.org/archives/1252](http://blog.regehr.org/archives/1252)

~~~
davidrusu
That's great to hear! It is a very interesting project

Can you explain why your goal is to implement these optimizations in llvm? Why
not have Souper as one of the optimization passes?

~~~
regehr
It turns out it's harder than you'd think to decide whether or not an
optimization is a good idea. Of course there are some relatively simple
optimizations that are obviously good, but a lot of those have already been
implemented. Also, I'm not sure how many people are going to want to add a
solver into their compilation path.

On the other hand, if we simply contribute optimizations then all LLVM users
benefit.

We're also using Souper to reveal imprecisions in LLVM dataflow analyses such
as known bits -- this turns out to work really well.

~~~
davidrusu
Ahh, I see. I assumed that any and all optimizations are good, that makes
sense.

Keep up the good work!

------
StefanKarpinski
I've used Souper a bunch of times on hand-written, performance-critical LLVM
code, hoping for some magic superoptimal version of the function. Even saving
a few instructions would help in these cases. Unfortunately, in my experience
Souper is the identity function: it has literally not once changed my LLVM
code in any way. If I'm doing something wrong, I'd love to know what. Perhaps
it's not expected that hand-written LLVM will have much room for improvement?
Is the intended target of optimization only expected to be fairly obviously
redundant machine-generated code?

~~~
andrewchambers
Working with llvm IR generally doesn't find as nice things compared to super
optimizing assembly instructions. This is because there are lots of esoteric
assembly instructions a human might not consider using that a machine can
brute force.

That is probably one source of problems for souper.

