This specific case (the large switch table replacing a lookup) is such an esoteric corner case I think it would be hard to convince clang to spend much more than a trivial bit of effort on fixing it.
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.
(the large switch table replacing a lookup)
Its not that esoteric, maintaining switches is more
intuitive and flexible than dealing with rigid lookup
table logic.
This specific case (the large switch table replacing a lookup) is such an esoteric corner case I think it would be hard to convince clang to spend much more than a trivial bit of effort on fixing it.
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.
(the large switch table replacing a lookup) Its not that esoteric, maintaining switches is more intuitive and flexible than dealing with rigid lookup table logic.
esoterism or not, according to the author the problem is a regression.