0
1
mirror of https://github.com/golang/go synced 2025-05-31 15:40:52 +00:00
Files
go/test
Matthew Dempsky 85fc765341 cmd/compile: optimize switch on strings
When compiling expression switches, we try to optimize runs of
constants into binary searches. The ordering used isn't visible to the
application, so it's unimportant as long as we're consistent between
sorting and searching.

For strings, it's much cheaper to compare string lengths than strings
themselves, so instead of ordering strings by "si <= sj", we currently
order them by "len(si) < len(sj) || len(si) == len(sj) && si <= sj"
(i.e., the lexicographical ordering on the 2-tuple (len(s), s)).

However, it's also somewhat cheaper to compare strings for equality
(i.e., ==) than for ordering (i.e., <=). And if there were two or
three string constants of the same length in a switch statement, we
might unnecessarily emit ordering comparisons.

For example, given:

    switch s {
    case "", "1", "2", "3": // ordered by length then content
        goto L
    }

we currently compile this as:

    if len(s) < 1 || len(s) == 1 && s <= "1" {
        if s == "" { goto L }
        else if s == "1" { goto L }
    } else {
        if s == "2" { goto L }
        else if s == "3" { goto L }
    }

This CL switches to using a 2-level binary search---first on len(s),
then on s itself---so that string ordering comparisons are only needed
when there are 4 or more strings of the same length. (4 being the
cut-off for when using binary search is actually worthwhile.)

So the above switch instead now compiles to:

    if len(s) == 0 {
        if s == "" { goto L }
    } else if len(s) == 1 {
        if s == "1" { goto L }
        else if s == "2" { goto L }
        else if s == "3" { goto L }
    }

which is better optimized by walk and SSA. (Notably, because there are
only two distinct lengths and no more than three strings of any
particular length, this example ends up falling back to simply using
linear search.)

Test case by khr@ from CL 195138.

Fixes .

Change-Id: I8eeebcaf7e26343223be5f443d6a97a0daf84f07
Reviewed-on: https://go-review.googlesource.com/c/go/+/195340
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-09-18 05:33:05 +00:00
..
2019-03-06 18:53:12 +00:00
2019-09-08 17:28:20 +00:00
2012-11-08 09:04:27 -08:00
2012-09-10 13:03:07 -07:00
2018-05-29 02:39:16 +00:00
2015-01-29 13:07:30 +00:00
2019-09-08 17:28:20 +00:00
2018-10-06 15:40:03 +00:00
2012-09-28 08:30:30 -07:00
2015-07-11 14:36:33 +00:00
2015-07-11 14:36:33 +00:00
2012-10-07 21:52:57 +02:00
2019-09-08 17:28:20 +00:00
2018-04-30 19:39:18 +00:00
2019-09-08 17:28:20 +00:00
2019-03-18 20:10:55 +00:00
2014-10-27 18:59:02 -04:00
2013-02-11 18:20:52 -05:00
2018-11-26 14:13:53 +00:00
2018-11-27 15:36:08 +00:00
2018-11-26 14:13:53 +00:00
2018-11-26 14:13:53 +00:00
2019-03-12 20:46:29 +00:00
2019-09-08 17:28:20 +00:00
2018-03-01 21:11:16 +00:00
2018-12-03 16:48:21 +00:00
2019-09-08 17:28:20 +00:00

The test directory contains tests of the Go tool chain and runtime. It includes black box tests, regression tests, and error output tests. They are run as part of all.bash.

To run just these tests, execute:

../bin/go run run.go

Standard library tests should be written as regular Go tests in the appropriate package.

The tool chain and runtime also have regular Go tests in their packages. The main reasons to add a new test to this directory are:

  • it is most naturally expressed using the test runner; or
  • it is also applicable to gccgo and other Go tool chains.