A Superoptimizer for LLVM IR
github.com
github.com
The scientific paper without reproducible environment.
The deep learning models with no weights.
The optimizer without benchmarks.
Compiling and profiling reasonably complex apps against baseline would be enough.
The idea of superoptimization is to find missed optimizations, which a human can review and then implement directly.
That sounds measurable.
Can it optimize sequences of shuffles? If so, it'd be worth a try, even if it takes hours (probably doesn't take that long?), I could let it run until it finds faster sequences than what I have now, and update my code.
But for it to be worth the time for me to figure out how to install and use it, I need some sort of expectation for what I'd get out of trying this instead of something else.
Example program 6: https://www.cs.utah.edu/~regehr/souper/output_6.html
int a, b;
void fn1() { b = a * ~1 == 1; }
By its nature Souper becomes less effective over time as its findings are incorporated into LLVM, so most of the trophies are old!
The new programming language without sample code on the landing page.
Anyway, at least the big Get Started button points to some code.
Besides, over half of website use is via mobile nowadays.
- Where are the benchmarks?
- Benchmarks aren't relevant; it's only for detecting possibilities.
- But it has some kind of direct replacement mode, why aren't there benchmarks for that?
- Crickets...
- Where is this used in practice?
- By developers who take its advice.
- Examples?
- Crickets...
Crickets...
That's not fair. They've published a paper which has lots of details: https://arxiv.org/pdf/1711.04422.pdf
> Performance of the SPEC benchmarks was also unevenly affected by Souper: five become faster and seven become slower. None of the differences was very large.
"The goal is to give compiler developers actionable advice about missing optimizations. To do this, someone uses sclang to extract Souper left-hand sides from programs of interest. Since Souper finds many more optimizations than developers could reasonably implement, the crux is ranking them in such a way that desirable optimizations are found early in the list. We are not aware of any single best ranking function, but rather we have created several such functions that can be used together or separately"
In the context of LLVM IR, there's a subtle issue which is even more important. LLVM IR is sufficiently divorced from actual hardware instructions to be a good basis for a cost model. I believe Souper is largely using instruction count as its cost model [1], which is going to really fall down when you handle i1 values, since most processors aren't capable of doing arithmetic on i1 values natively, and converting the result of a comparison instruction into one that can be reasoned about with boolean circuits can involve several extra instructions.
[1] Regehr's original blog post on the matter says instructions are cost 1, constants and phis cost 0, and selects and div/rem cost 3. sexts/zexts/truncs aren't explicitly modeled, and so also presumably cost 0. So it's mostly instruction cost.
But if the company doesn't want to provide any kind of ongoing support (eg. if that employee leaves the company and abandons it), then they say this.