The paper mentions that Souper links against LLVM 3.9, but a recent commit on GitHub states that dependencies have been bumped to LLVM 5.0, the most recent version.
The abstract is not very clear, if you ask me. I would have expected at least an indication of the usefulness of this optimizer in terms of resulting speed, or an indication of how far we are from using this technique in production settings.
An Souper-optimized Clang-3.9 binary is almost 3 MB (4.4%) smaller than one built without Souper, though it is also about 2% slower.
It sounds like the perceived value is more about finding clever optimization patterns and explaining them to the Clang and Visual C++ developers for them to integrate.
If we can automatically derive compiler optimizations, we might be able to sidestep some of the substantial engineering challenges involved in creating and maintaining a high-quality compiler
I think it's clear, but you may have assumed it's about something it's not? It's about saving effort in writing an optimizing compiler. Have you ever looked at how many and how big LLVM's optimization passes are?
The automatically derived passes may not result in code that's as fast as the hand-written passes. I assume they would have mentioned that if it were the case. But they take less effort to develop.
7 comments
[ 2.9 ms ] story [ 31.9 ms ] threadhttps://github.com/google/souper
The paper mentions that Souper links against LLVM 3.9, but a recent commit on GitHub states that dependencies have been bumped to LLVM 5.0, the most recent version.
https://blog.regehr.org/archives/1192
https://blog.regehr.org/archives/1252
But then a paper is a whole nuther thing.
An Souper-optimized Clang-3.9 binary is almost 3 MB (4.4%) smaller than one built without Souper, though it is also about 2% slower.
It sounds like the perceived value is more about finding clever optimization patterns and explaining them to the Clang and Visual C++ developers for them to integrate.
I think it's clear, but you may have assumed it's about something it's not? It's about saving effort in writing an optimizing compiler. Have you ever looked at how many and how big LLVM's optimization passes are?
The automatically derived passes may not result in code that's as fast as the hand-written passes. I assume they would have mentioned that if it were the case. But they take less effort to develop.