3 ms·
You can already spend as much as you'd like on optimizations if you are using LLVM. Just use a superoptimizer [0]: clang -Xclang -load -Xclang libsouperPas
by fluffything 6y ago
You can already spend as much as you'd like on optimizations if you are using LLVM. Just use a superoptimizer [0]:
clang -Xclang -load -Xclang libsouperPass.so -mllvm -z3-path=/usr/bin/z3
, or increase the inlining heuristics..., or just create your own optimization strategy like rustc does [1], or...
LLVM is super configurable, so you can make it do whatever you want.
Clang defaults are tuned for the optimizations that give you the most bang for the time you put in, while still being able to compile a Web browser like Chrome or Firefox, or a whole Linux distribution packages, in a reasonable amount of time.
If you don't care about how long compile-times take, then you are not a "target" clang user, but you can just pass clang extra arguments like those mentioned above, or even fork it to add your own -Oeternity option that takes in your project and tries to compile it for a millenia on a super computer for that little extra 0.00001% reduction in code size, at best.
Because often, code compiled with -O3 is slower than code compiled with -O2. Because "more optimizations" do not necessarily mean "faster code" like you seem tobe suggesting.
[0]: https://github.com/google/souper https://github.com/google/souper
[1]: https://github.com/rust-lang/rust/blob/master/src/rustllvm/PassWrapper.cpp#L713 https://github.com/rust-lang/rust/blob/master/src/rustllvm/P...
- CalChris 6y agoHas anyone ever done a Pareto frontier analysis on this? Specifically, this would be for speed rather than size.
- fluffything 6y agoWhat would you expect to learn and how would you do this? I can't imagine anything useful coming out of it.
- noch 6y ago> Because often, code compiled with -O3 is slower than code compiled with -O2. Because "more optimizations" do not necessarily mean "faster code" like you seem tobe suggesting. Indeed, due to patterns of resource use and availability (e.g. the memory wall[0]), compiler optimisations can only solve 1-10% of performance problems a piece of code might have. To paraphrase Mike Acton: The vast majority of your code consists of things the compiler can't reason about.[1] [0]: https://en.m.wikipedia.org/wiki/Random-access_memory#Memory_wall https://en.m.wikipedia.org/wiki/Random-access_memory#Memory_... [1]: [Mike Acton, "How to Write Code the Compiler Can Actually Optimize", GDC2015.](https://m.youtube.com/watch?feature=youtu.be&v=x61H6qEtK08&t=20m https://m.youtube.com/watch?feature=youtu.be&v=x61H6qEtK08&t...)