A Clang regression related to switch statements and inlining
nicula.xyz
nicula.xyz
The associated posts are interesting, so thanks to the author for that. I think it's more likely to see that clang/gcc do some value-range analysis on lookup tables (as suggested in the first post). I can see a decent amount of general value in that case.
If anything, clang should probably recognize switch case N return M that mimic a lookup table and convert them back to lookup tables, after which they can be optimized with a dedicate LUT-aware pass.
This whole investigation started because I was writing some Rust code with a couple of small `match`es, and for some reason they weren't being optimized to a lookup table. I wrote a more minimal reproduction of that issue in C++ and eventually found the Clang regression. Since Rust also uses LLVM, `match`es suffer from the same regression (depending on which Rust version you're using).
Yes.
> If you run LLVM 18's `opt` on bytecode generated by Clang 19 and then compile it, does it also generate the same bad assembly?
No. If you pass the LLVM IR bitcode generated by Clang 18 to Clang 19, then the assembly is good.
I called it a 'Clang regression' in the sense that the way in which I discovered and tested this difference in performance was via Clang. So from a typical user's perspective (who doesn't care about the inner workings and distinct components of Clang), this is a 'Clang regression'.