-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: Switch on four-byte string constants repeats comparisons #53333
Comments
We should also do that with 8 bytes on 64 bits architectures with support for 8 bytes immediates in comparisons. |
The GOSSAFUNC dump already shows both the literal comparisons and the runtime.cmpstring call in the AST repr: . . IF-Cond |
I think the reason it is this way is that the top clause of the binary search is a The relevant code is in
I think we'd just have to implement that. It will be somewhat complicated I think (e.g. endianness matters), but not too bad. |
I looked at this a bit more. I originally thought we could just optimize generic string vs. constant string ordered comparisons, and that would fix this issue also. But those comparisons are very tough, mostly because we don't know anything about the length of the nonconstant string. We can't easily read the nonconstant string because we need to check the length to be sure we're still in bounds. ==/!= comparisons avoid that by comparing the length first. |
Change https://go.dev/cl/414894 mentions this issue: |
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?What did you do?
What did you expect to see?
I expected the switch to be compiled to a check for len(ext) == 4 followed by a binary search that has a single CMPL for each case.
What did you see instead?
A binary search where each case has a length check against four, followed by a CMPL; worse, the binary search is preceded by a runtime.cmpstring against ".htm", so that comparison occurs twice (it also occurs as a CMPL against $1836345390).
The generated code is closer to expected when there is one fewer case. Then it only repeats the length check.
The text was updated successfully, but these errors were encountered: