mirror of
https://github.com/golang/go
synced 2024-09-15 22:20:06 +00:00
e244a7a7d3
Add patterns to match common idioms for EXTR, BFI, BFXIL, SBFIZ, SBFX, UBFIZ and UBFX opcodes. go1 benchmarks results on Amberwing: name old time/op new time/op delta FmtManyArgs 786ns ± 2% 714ns ± 1% -9.20% (p=0.000 n=10+10) Gzip 437ms ± 0% 402ms ± 0% -7.99% (p=0.000 n=10+10) FmtFprintfIntInt 196ns ± 0% 182ns ± 0% -7.28% (p=0.000 n=10+9) FmtFprintfPrefixedInt 207ns ± 0% 199ns ± 0% -3.86% (p=0.000 n=10+10) FmtFprintfFloat 324ns ± 0% 316ns ± 0% -2.47% (p=0.000 n=10+8) FmtFprintfInt 119ns ± 0% 117ns ± 0% -1.68% (p=0.000 n=10+9) GobDecode 12.8ms ± 2% 12.6ms ± 1% -1.62% (p=0.002 n=10+10) JSONDecode 94.4ms ± 1% 93.4ms ± 0% -1.10% (p=0.000 n=10+10) RegexpMatchEasy0_32 247ns ± 0% 245ns ± 0% -0.65% (p=0.000 n=10+10) RegexpMatchMedium_32 314ns ± 0% 312ns ± 0% -0.64% (p=0.000 n=10+10) RegexpMatchEasy0_1K 541ns ± 0% 538ns ± 0% -0.55% (p=0.000 n=10+9) TimeParse 450ns ± 1% 448ns ± 1% -0.42% (p=0.035 n=9+9) RegexpMatchEasy1_32 244ns ± 0% 243ns ± 0% -0.41% (p=0.000 n=10+10) GoParse 6.03ms ± 0% 6.00ms ± 0% -0.40% (p=0.002 n=10+10) RegexpMatchEasy1_1K 779ns ± 0% 777ns ± 0% -0.26% (p=0.000 n=10+10) RegexpMatchHard_32 2.75µs ± 0% 2.74µs ± 1% -0.06% (p=0.026 n=9+9) BinaryTree17 11.7s ± 0% 11.6s ± 0% ~ (p=0.089 n=10+10) HTTPClientServer 89.1µs ± 1% 89.5µs ± 2% ~ (p=0.436 n=10+10) RegexpMatchHard_1K 78.9µs ± 0% 79.5µs ± 2% ~ (p=0.469 n=10+10) FmtFprintfEmpty 58.5ns ± 0% 58.5ns ± 0% ~ (all equal) GobEncode 12.0ms ± 1% 12.1ms ± 0% ~ (p=0.075 n=10+10) Revcomp 669ms ± 0% 668ms ± 0% ~ (p=0.091 n=7+9) Mandelbrot200 5.35ms ± 0% 5.36ms ± 0% +0.07% (p=0.000 n=9+9) RegexpMatchMedium_1K 52.1µs ± 0% 52.1µs ± 0% +0.10% (p=0.000 n=9+9) Fannkuch11 3.25s ± 0% 3.26s ± 0% +0.36% (p=0.000 n=9+10) FmtFprintfString 114ns ± 1% 115ns ± 0% +0.52% (p=0.011 n=10+10) JSONEncode 20.2ms ± 0% 20.3ms ± 0% +0.65% (p=0.000 n=10+10) Template 91.3ms ± 0% 92.3ms ± 0% +1.08% (p=0.000 n=10+10) TimeFormat 484ns ± 0% 495ns ± 1% +2.30% (p=0.000 n=9+10) There are some opportunities to improve this change further by adding patterns to match the "extended register" versions of ADD/SUB/CMP, but I think that should be evaluated on its own. The regressions in Template and TimeFormat would likely be recovered by this, as they seem to be due to generating: ubfiz x0, x0, #3, #8 add x1, x2, x0 instead of add x1, x2, x0, lsl #3 Change-Id: I5644a8d70ac7a98e784a377a2b76ab47a3415a4b Reviewed-on: https://go-review.googlesource.com/88355 Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> |
||
---|---|---|
.. | ||
arithmetic.go | ||
bitfield.go | ||
bits.go | ||
issue22703.go | ||
math.go | ||
mathbits.go | ||
memcombine.go | ||
movesmall.go | ||
README | ||
rotate.go |
// Copyright 2018 The Go Authors. All rights reserved. // Use of this source code is governed by a BSD-style // license that can be found in the LICENSE file. The codegen directory contains code generation tests for the gc compiler. - Introduction The test harness compiles Go code inside files in this directory and then matches the generated assembly (the output of `go tool compile -S`) against a set of regexps specified in comments that follow a special syntax (described below). The test driver is implemented as a step of the top-level test/run.go suite, called "asmcheck". The codegen tests run during all.bash, but can also be run in isolation by using $ ../bin/go run run.go -v codegen in the top-level test directory. The test harness compiles the tests with the same go toolchain that is used to run run.go. After writing tests for a newly added codegen transformation, it can be useful to first run the test harness with a toolchain from a released Go version (and verify that the new tests fail), and then re-runnig the tests using the devel toolchain. - Regexps comments syntax Instructions to match are specified inside plain comments that start with an architecture tag, followed by a colon and a quoted Go-style regexp to be matched. For example, the following test: func Sqrt(x float64) float64 { // amd64:"SQRTSD" // arm64:"FSQRTD" return math.Sqrt(x) } verifies that math.Sqrt calls are intrinsified to a SQRTSD instruction on amd64, and to a FSQRTD instruction on arm64. It is possible to put multiple architectures checks into the same line, as: // amd64:"SQRTSD" arm64:"FSQRTD" although this form should be avoided when doing so would make the regexps line excessively long and difficult to read. Comments that are on their own line will be matched against the first subsequent non-comment line. Inline comments are also supported; the regexp will be matched against the code found on the same line: func Sqrt(x float64) float64 { return math.Sqrt(x) // arm:"SQRTD" } It's possible to specify a comma-separated list of regexps to be matched. For example, the following test: func TZ8(n uint8) int { // amd64:"BSFQ","ORQ\t\\$256" return bits.TrailingZeros8(n) } verifies that the code generated for a bits.TrailingZeros8 call on amd64 contains both a "BSFQ" instruction and an "ORQ $256". Note how the ORQ regex includes a tab char (\t). In the Go assembly syntax, operands are separated from opcodes by a tabulation. Regexps can be quoted using either " or `. Special characters must be escaped accordingly. Both of these are accepted, and equivalent: // amd64:"ADDQ\t\\$3" // amd64:`ADDQ\t\$3` and they'll match this assembly line: ADDQ $3 Negative matches can be specified using a - before the quoted regexp. For example: func MoveSmall() { x := [...]byte{1, 2, 3, 4, 5, 6, 7} copy(x[1:], x[:]) // arm64:-".*memmove" } verifies that NO memmove call is present in the assembly generated for the copy() line. - Remarks, and Caveats -- Write small test functions As a general guideline, test functions should be small, to avoid possible interactions between unrelated lines of code that may be introduced, for example, by the compiler's optimization passes. Any given line of Go code could get assigned more instructions that it may appear from reading the source. In particular, matching all MOV instructions should be avoided; the compiler may add them for unrelated reasons and this may render the test ineffective. -- Line matching logic Regexps are always matched from the start of the instructions line. This means, for example, that the "MULQ" regexp is equivalent to "^MULQ" (^ representing the start of the line), and it will NOT match the following assembly line: IMULQ $99, AX To force a match at any point of the line, ".*MULQ" should be used. For the same reason, a negative regexp like -"memmove" is not enough to make sure that no memmove call is included in the assembly. A memmove call looks like this: CALL runtime.memmove(SB) To make sure that the "memmove" symbol does not appear anywhere in the assembly, the negative regexp to be used is -".*memmove".