cmd/compile: jump table optimisation is not utilised when a case has multiple clauses

[renthraysk]

What version of Go are you using (go version)?

$ go version
go version go1.19.2 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What did you do?

https://go.dev/play/p/LSrP_ch-8f1

What did you expect to see?

Both f1() & f2() to utilize jump table optimization, as both functions are functionally identical.

What did you see instead?

f1() uses jump table optimization as it has 8 distinct case clauses.
f2() reverts to a chain of comparisons.

[randall77]

This is kind of intentional.
The intent is to measure the number of comparisons needed to implement the switch as a binary search. In f2, there are really only 7 different ranges that need to be distinguished. Consider:

	switch x {
	case 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10:
		println("<11")
	}

That also doesn't use a jump table, as it doesn't take many comparisons to implement it.

We probably shoudn't generate the jump table for f1, but we don't recognize that we can join cases when the first case is a naked fallthrough. (And also we don't recognize duplicate, in your case empty, code blocks either, which would also allow joining cases.)

And of course the number 8 is kind of arbitrary. We had to pick some threshold.

[dr2chase]

Close as working as intended / not a bug?