Well, I don’t really remember “many” regressions (of any kind) for the 3.7.1 → 3.9 updates. The only one that was attributed to it at some point that I can remember was LLVM generates bad code on newer architercures · Issue #19976 · JuliaLang/julia · GitHub, which was not an LLVM regression. In fact, there’s still LLVM bugs that affects us that’ll be fixed with an upgrade like floating point `div` differs in optimized code · Issue #14089 · JuliaLang/julia · GitHub
We had the most issue with the 3.3 → 3.7.1 upgrade but that’s just because of a major API change in LLVM. Nothing like that has happened after 3.7 yet and AFAICT the 3.7 → 3.9 upgrade was very smooth.
The only issue I can think of that is affecting us when upgrading to 5.0 is GC frame lowering doesn't handle vector well · Issue #23949 · JuliaLang/julia · GitHub, which is due to the change in how we use LLVM, not LLVM changes. That can easily be changed to match 3.9 behavior if needed.
If we don’t upgrade to LLVM 5.0, we’ll have
- No avx support on 32bit (I guess that’s not a big deal)
- No ryzen support
- No avx512 support
https://github.com/JuliaLang/julia/pull/21849 helps with 2 but still, not supporting the latest processor from both Intel and AMD months after their release looks pretty bad.
Unless there’s significantly more features added in the 6.0 cycle, I imaging that’s requires much less backporting effort. Both from the number of patches, and from how much other code have been changed.
Also, the thread about getting LLVM compilation performance good again happens in 3.9 time frame so I expect the compilation performance to not get worse as much after that. But in the end, since I’m not using the generic binary I guess I don’t care that much which LLVM is used by default… It mainly affect how much I want to help getting LLVM 5.0 working for use cases I don’t have.