4 ms·

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?

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

vok 11y ago
This new paper covers some state-of-the-art techniques: https://www.eecs.berkeley.edu/~mangpo/www/papers/lens-asplos16.pdf https://www.eecs.berkeley.edu/~mangpo/www/papers/lens-asplos...
- tikhonj 11y ago
  To be clear: that is a distinct project that merely relies on a similar set of techniques at a high level. If my understanding of Souper is correct, it's using synthesis to improve optimization rules inside LLVM. Lens, on the other hand, uses synthesis to optimize code directly with some neat algorithmic improvements to prune the search space. It targets ARM and, of all things, GreenArrays (a weird, extremely low-energy Forth-based architecture). To be clear: I think both projects are interesting, as are other efforts in the field (ie Aiken at Stanford has done some cool stuff). Program synthesis is a topic I'm definitely interested in. But if you're interested more in LLVM and less in synthesis in general, this paper is going to be less interesting.
  - PeCaN 11y ago
    GreenArrays's main claim to fame is that it's a fully asynchronous architecture (no central clock). Oh, and it's from Chuck Moore (the Forth guy and kinda the Mike Pall of hardware design). I had no idea Lens targets it. That's awesome.
    - tikhonj 11y ago
      Yeah, the project came out of Chlorophyll[1] which was a compiler for GreenArrays that used program synthesis for optimization. I imagine ARM has more immediate practical applications and useful benchmarks, but it came second—I assume out of a collaboration with Qualcomm Research. [1]: http://pl.eecs.berkeley.edu/projects/chlorophyll/ http://pl.eecs.berkeley.edu/projects/chlorophyll/
regehr 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      Ahh, I see. I assumed that any and all optimizations are good, that makes sense. Keep up the good work!

vok 11y ago

This new paper covers some state-of-the-art techniques: https://www.eecs.berkeley.edu/~mangpo/www/papers/lens-asplos16.pdf https://www.eecs.berkeley.edu/~mangpo/www/papers/lens-asplos...

tikhonj 11y ago
To be clear: that is a distinct project that merely relies on a similar set of techniques at a high level. If my understanding of Souper is correct, it's using synthesis to improve optimization rules inside LLVM. Lens, on the other hand, uses synthesis to optimize code directly with some neat algorithmic improvements to prune the search space. It targets ARM and, of all things, GreenArrays (a weird, extremely low-energy Forth-based architecture). To be clear: I think both projects are interesting, as are other efforts in the field (ie Aiken at Stanford has done some cool stuff). Program synthesis is a topic I'm definitely interested in. But if you're interested more in LLVM and less in synthesis in general, this paper is going to be less interesting.
- PeCaN 11y ago
  GreenArrays's main claim to fame is that it's a fully asynchronous architecture (no central clock). Oh, and it's from Chuck Moore (the Forth guy and kinda the Mike Pall of hardware design). I had no idea Lens targets it. That's awesome.
  - tikhonj 11y ago
    Yeah, the project came out of Chlorophyll[1] which was a compiler for GreenArrays that used program synthesis for optimization. I imagine ARM has more immediate practical applications and useful benchmarks, but it came second—I assume out of a collaboration with Qualcomm Research. [1]: http://pl.eecs.berkeley.edu/projects/chlorophyll/ http://pl.eecs.berkeley.edu/projects/chlorophyll/

regehr 11y ago

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 11y ago
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 11y ago
  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 11y ago
    Ahh, I see. I assumed that any and all optimizations are good, that makes sense. Keep up the good work!