This transform is cheap enough that there is no need to bail outReduceSwitchRange only ran if the switch statement wasn't "dense". AlsoThis is a very cheap transform, the GCD calculation is unnecessary and wastefulif it can make improvements should be run, as it requires expensive division inso run it all the compilertime. No programming languages I know of allow these numbers to be created programmatically(that is all IsSwitchDense did, so there is no point in getting too smart and trying to do constant division on the keys with the GCD.it did not determine if a jump table or lookup table should be generated) Also:
Add a clz/ctz keyed transform.
Add a second patch that changes SwitchToLookupTable
There were a number of cases where a table was smaller and we still didn't use it, and*Do not do an expensive general GCD calculation when only countTrailingZeros() information is used from it.
also i8 tables are small enough that we should use them* Re-order values to ideal with a subtraction, instead of only covering some cases by treating the values as signed.
* Implement the ctlz/cttz transform that was suggested in the comments. AlsoThis transform is still not ideal, remove xor and and when producing a covered table.
see PR 39046as SwitchToLookupTable doesn't know the potential range of values has been reduced, and there is no good plumbing in LLVM (that I know of) to get that information.