7 ms·
In theory, you could generate better code after having observed the actual arguments to various functions and recompile while treating them as constants. Basica
by sfink 7y ago
In theory, you could generate better code after having observed the actual arguments to various functions and recompile while treating them as constants. Basically profile-guided (re)optimization. But the observation would slow down the initial code, it would be a large implementation effort, and the gains would be dubious imho. Especially given how much information was already lost via the initial AOT (ahead of time) optimizing compile; you might need to keep the original source around or something.
Unlikely to happen.
- dathinab 7y agoThanks. I considered this scenario as llvm does somewhat support profile-guided optimizations but it would be a fundamental change where we go from "unoptimized" to "optimized-with-tracing" instead of optimized, so that step could still have optimization upgrade hooks, so we still wouldn't need a downgrade to "base-line". I guess. I agree that it's anyway unlikely to happen, at least in the browser. I could imagine that some WebAssembly based cloud provider (or similar) would be potentially interested in generating profiles and then use that for better optimizations in other instances (so still no down-/upgrade ).
- mappu 7y ago> you could generate better code after having observed the actual arguments to various functions and recompile while treating them as constants This transformation is valid for pure functions; therefore you can mark it constexpr before compiling to WASM. There's the `constexpr-everything` project (among others) that uses libclang to apply constexpr to all legal functions/expressions in a codebase. That's for C++ - Rust is working on `const fn`.
- saagarjha 7y ago> This transformation is valid for pure functions; therefore you can mark it constexpr before compiling to WASM. It's also valid for non-pure functions at runtime.