- 28 Feb, 2018 4 commits
-
-
Robert Griesemer authored
This change enables printing of relative column information if a prior line directive specified a valid column. If there was no line directive, or the line directive didn't specify a column (or the -C flag is specified), no column information is shown in file positions. Implementation: Column values (and line values, for that matter) that are zero are interpreted as "unknown". A line directive that doesn't specify a column records that as a zero column in the respective PosBase data structure. When computing relative columns, a relative value is zero of the base's column value is zero. When formatting a position, a zero column value is not printed. To make this work without special cases, the PosBase for a file is given a concrete (non-0:0) position 1:1 with the PosBase's line and column also being 1:1. In other words, at the position 1:1 of a file, it's relative positions are starting with 1:1 as one would expect. In the package syntax, this requires self-recursive PosBases for file bases, matching what cmd/internal/src.PosBase was already doing. In src.PosBase, file and inlining bases also need to be based at 1:1 to indicate "known" positions. This change completes the cmd/compiler part of the issue below. Fixes #22662. Change-Id: I6c3d2dee26709581fba0d0261b1d12e93f1cba1a Reviewed-on: https://go-review.googlesource.com/97375Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Hana Kim authored
Update #24081 Change-Id: Ieccfb03c51e86f35d4629a42959c80570bd93c33 Reviewed-on: https://go-review.googlesource.com/97555Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Heschi Kreinick authored
This reverts commit 230b0bad. Reason for revert: breaking the build. Fixes #24165 Change-Id: I9d8dda59f97a47e5c436f1c061b34ced82bde8ec Reviewed-on: https://go-review.googlesource.com/97575 Run-TryBot: Heschi Kreinick <heschi@google.com> Reviewed-by:
Robert Griesemer <gri@golang.org> Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Kunpei Sakai authored
Updates #23834 Change-Id: If05001f9fd6b97d72069f440102eec6e371908dd Reviewed-on: https://go-review.googlesource.com/97016 Run-TryBot: Kunpei Sakai <namusyaka@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 27 Feb, 2018 22 commits
-
-
Michael Fraenkel authored
Updates #23834. Change-Id: I1789525a992d37aae9e9b69c1e9d91437d3d0d3b Reviewed-on: https://go-review.googlesource.com/97001 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Keith Randall authored
The first word of an interface is a pointer, but for the purposes of GC we don't need to treat it as such. 1. If it is a non-empty interface, the pointer points to an itab which is always in persistentalloc space. 2. If it is an empty interface, the pointer points to a _type. a. If it is a compile-time-allocated type, it points into the read-only data section. b. If it is a reflect-allocated type, it points into the Go heap. Reflect is responsible for keeping a reference to the underlying type so it won't be GCd. If we ever have a moving GC, we need to change this for 2b (as well as scan itabs to update their itab._type fields). Write barriers on the first word of interfaces have already been removed. Change-Id: I643e91d7ac4de980ac2717436eff94097c65d959 Reviewed-on: https://go-review.googlesource.com/97518 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:David Chase <drchase@google.com>
-
isharipo authored
Minimizes the amount of "TODO" stuff in test suite of cmd/asm/internal/asm/testdata/amd64enc.s. Some instructions were already implemented, but test cases for them were commented-out. Does not enable MMX instructions, calls/jumps and some segment registers instructions. -- Affected instructions -- BLENDVPD, BLENDVPS BSWAPW CBW CDQE CLAC CLFLUSHOPT CMPXCHG16B CRC32B, CRC32L, CRC32W CWDE FBLD FBSTP FCMOVB FCMOVBE FCMOVE FCMOVNB FCMOVNBE FCMOVU FCOMI FCOMIP IMUL3L, IMUL3Q, IMUL3W ICEBP, INT INVPCID LARQ LGDT, LIDT, LLDT LMSW LTR LZCNTL, LZCNTQ, LZCNTW MONITOR MOVBELL, MOVBEQQ, MOVBEWW MOVBQZX MOVQ MOVSWW, MOVZWW MWAIT NOPL, NOPW PBLENDVB PEXTRW RDPKRU RDRANDL, RDRANDQ, RDRANDW RDSEEDL, RDSEEDQ, RDSEEDW RDTSCP SAHF SGDT, SIDT SLDTL, SLDTQ, SLDTW SMSWL, SMSWQ, SMSWW STAC STRL, STRQ, STRW SYSENTER, SYSENTER64 SYSEXIT, SYSEXIT64 SHA256RNDS2 TZCNTL, TZCNTQ, TZCNTW UD1, UD2 WRPKRU XRSTOR, XRSTOR64 XRSTORS, XRSTORS64 XSAVE, XSAVE64 XSAVEC, XSAVEC64 XSAVEOPT, XSAVEOPT64 XSAVES, XSAVES64 XSETBV Fixes #6739 Change-Id: I8b125d9a5ea39bb4b9da7e66a63a16f609cef376 Reviewed-on: https://go-review.googlesource.com/97235 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Daniel Martí authored
Make the hasSideEffects func use type information to see if a CallExpr is a type conversion or not. In case it is, there cannot be any side effects. Now that vet always has type information, we can afford to use it here. Update the tests and remove the TODO there too. Change-Id: I74fdacf830aedf2371e67ba833802c414178caf1 Reviewed-on: https://go-review.googlesource.com/79536Reviewed-by:
-
Ilya Tocar authored
Explicitly whitelist args of OpSelect{1|2} that zero upper 32 bits. Use better values in corresponding test. This should have been a part of CL 96815, but it was submitted, before relevant comments. Change-Id: Ic85d90a4471a17f6d64f8f5c405f21378bf3a30d Reviewed-on: https://go-review.googlesource.com/97295 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Darshan Parajuli authored
Change-Id: I12f96a9397cfaebe11e616543d804bd62cd72da0 Reviewed-on: https://go-review.googlesource.com/97379Reviewed-by:
-
Josh Bleecher Snyder authored
Follow-up to CL 94256. Change-Id: I61c450dee5975492192453738f734f772e95c1a5 Reviewed-on: https://go-review.googlesource.com/97515Reviewed-by:
-
ChrisALiles authored
Fixes #20304 Change-Id: I52ee02d1602ed7fffc96b27fd60990203c771aaf Reviewed-on: https://go-review.googlesource.com/94256 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Ilya Tocar authored
On amd64 we optimize encoding/binary.BigEndian.PutUint{16,32,64} into bswap + single store, but strangely enough not LittleEndian.PutUint{16,32}. We have similar rules, but they use 64-bit shifts everywhere, and fail for 16/32-bit case. Add rules that matchLittleEndian.PutUint, and relevant tests. Performance results: LittleEndianPutUint16-6 1.43ns ± 0% 1.07ns ± 0% -25.17% (p=0.000 n=9+9) LittleEndianPutUint32-6 2.14ns ± 0% 0.94ns ± 0% -56.07% (p=0.019 n=6+8) LittleEndianPutUint16-6 1.40GB/s ± 0% 1.87GB/s ± 0% +33.24% (p=0.000 n=9+9) LittleEndianPutUint32-6 1.87GB/s ± 0% 4.26GB/s ± 0% +128.54% (p=0.000 n=8+8) Discovered, while looking at ethereum_ethash from community benchmarks Change-Id: Id86d5443687ecddd2803edf3203dbdd1246f61fe Reviewed-on: https://go-review.googlesource.com/95475 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Matthew Dempsky authored
We accidentally overlooked needing to still visit Ninit for OIF statements with constant conditions in golang.org/cl/96778. Fixes #24120. Change-Id: I5b341913065ff90e1163fb872b9e8d47e2a789d2 Reviewed-on: https://go-review.googlesource.com/97475 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Heschi Kreinick authored
LLVM tools, particularly lldb and dsymutil, don't support base address selection entries in location lists. When targeting GOOS=darwin, mode, have the linker translate location lists to CU-relative form instead. Technically, this isn't necessary when linking internally, as long as nobody plans to use anything other than Delve to look at the DWARF. But someone might want to use lldb, and it's really confusing when dwarfdump shows gibberish for the location entries. The performance cost isn't noticeable, so enable it even for internal linking. Doing this in the linker is a little weird, but it was more expensive in the compiler, probably because the compiler is much more stressful to the GC. Also, if we decide to only do it for external linking, the compiler can't see the link mode. Benchmark before and after this commit on Mac with -dwarflocationlists=1: name old time/op new time/op delta StdCmd 21.3s ± 1% 21.3s ± 1% ~ (p=0.310 n=27+27) Only StdCmd is relevant, because only StdCmd runs the linker. Whatever the cost is here, it's not very large. Change-Id: I200246dedaee4f824966f7551ac95f8d7123d3b1 Reviewed-on: https://go-review.googlesource.com/89535Reviewed-by:
-
Tobias Klauser authored
Avoid an unnecessary MOVL/MOVQ. Follow CL 97377 Change-Id: Ic43976d6b0cece3ed455496d18aedd67e0337d3f Reviewed-on: https://go-review.googlesource.com/97358 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Tobias Klauser authored
The pipe2 syscall is part of OpenBSD since version 5.7 and thus exists in all officially supported versions. Follows CL 38426 and CL 94035 Change-Id: I8f93ecbc89664241f1b6b0d069e948776941b1d0 Reviewed-on: https://go-review.googlesource.com/97356 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by:
-
Philip Hofer authored
The branchelim pass makes some blocks unreachable, but does not remove them from Func.Values. Consequently, ssacheck complains when it finds a block with a non-zero likeliness value but no successors. Fixes #24014 Change-Id: I2dcf1d8f4e769a2f363508dab3b11198ead336b6 Reviewed-on: https://go-review.googlesource.com/96075Reviewed-by:
-
Josh Bleecher Snyder authored
Minor improvements, noticed while investigating other things. Shorten the prologue. Make branch direction better for static branch prediction; the most common case by far is switching stacks (g==curg). Change-Id: Ib2211d3efecb60446355cda56194221ccb78057d Reviewed-on: https://go-review.googlesource.com/97377 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joe Tsai authored
When a var or const declaration contains a mixture of exported and unexported identifiers, replace the unexported identifiers with underscore. Otherwise, the LHS and the RHS may mismatch or the declaration may mismatch with an iota from above. Fixes #22426 Change-Id: Icd5fb81b4ece647232a9f7d05cb140227091e9cb Reviewed-on: https://go-review.googlesource.com/94877 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
erifan01 authored
Improve performance by reducing unnecessary function calls Benchmarks: Tme old time/op new time/op delta Cosh-8 229ns ± 0% 138ns ± 0% -39.74% (p=0.008 n=5+5) Sinh-8 231ns ± 0% 139ns ± 0% -39.83% (p=0.008 n=5+5) Change-Id: Icab5485849bbfaafca8429d06b67c558101f4f3c Reviewed-on: https://go-review.googlesource.com/85477Reviewed-by:
-
Josh Bleecher Snyder authored
Change-Id: I855268a4c0d07ad602ec90f5da66422d3d87c5f2 Reviewed-on: https://go-review.googlesource.com/94595 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Giovanni Bajo authored
Bit-test rules failed to match when matching the highest bit of a word because operands in SSA are signed int64. Fix them by treating them as unsigned (and correctly handling 32-bit operands as well). Tests will be added in next CL. Change-Id: I491c4e88e7e2f87e9bb72bd0d9fa5d4025b90736 Reviewed-on: https://go-review.googlesource.com/94765Reviewed-by:
-
Giovanni Bajo authored
Spotted while working on #18943, it triggers once during bootstrap. Change-Id: Ia4330ccc6395627c233a8eb4dcc0e3e2a770bea7 Reviewed-on: https://go-review.googlesource.com/94764Reviewed-by:
-
Chad Rosier authored
This reduces the go tool binary on arm64 by 12k. go1 results on Amberwing: name old time/op new time/op delta RegexpMatchEasy0_32 249ns ± 0% 249ns ± 0% ~ (p=0.087 n=10+10) RegexpMatchEasy0_1K 584ns ± 0% 584ns ± 0% ~ (all equal) RegexpMatchEasy1_32 246ns ± 0% 246ns ± 0% ~ (p=1.000 n=10+10) RegexpMatchEasy1_1K 806ns ± 0% 806ns ± 0% ~ (p=0.706 n=10+9) RegexpMatchMedium_32 314ns ± 0% 314ns ± 0% ~ (all equal) RegexpMatchMedium_1K 52.1µs ± 0% 52.1µs ± 0% ~ (p=0.245 n=10+8) RegexpMatchHard_32 2.75µs ± 1% 2.75µs ± 1% ~ (p=0.690 n=10+10) RegexpMatchHard_1K 78.9µs ± 0% 78.9µs ± 1% ~ (p=0.295 n=9+9) FmtFprintfEmpty 58.5ns ± 0% 58.5ns ± 0% ~ (all equal) FmtFprintfString 112ns ± 0% 112ns ± 0% ~ (all equal) FmtFprintfInt 117ns ± 0% 116ns ± 0% -0.85% (p=0.000 n=10+10) FmtFprintfIntInt 181ns ± 0% 181ns ± 0% ~ (all equal) FmtFprintfPrefixedInt 222ns ± 0% 224ns ± 0% +0.90% (p=0.000 n=9+10) FmtFprintfFloat 318ns ± 1% 322ns ± 0% ~ (p=0.059 n=10+8) FmtManyArgs 736ns ± 1% 735ns ± 0% ~ (p=0.206 n=9+9) Gzip 437ms ± 0% 436ms ± 0% -0.25% (p=0.000 n=10+10) HTTPClientServer 89.8µs ± 1% 90.2µs ± 2% ~ (p=0.393 n=10+10) JSONEncode 20.1ms ± 1% 20.2ms ± 1% ~ (p=0.065 n=9+10) JSONDecode 94.2ms ± 1% 93.9ms ± 1% -0.42% (p=0.043 n=10+10) GobDecode 12.7ms ± 1% 12.8ms ± 2% +0.94% (p=0.019 n=10+10) GobEncode 12.1ms ± 0% 12.1ms ± 0% ~ (p=0.052 n=10+10) Mandelbrot200 5.06ms ± 0% 5.05ms ± 0% -0.04% (p=0.000 n=9+10) TimeParse 450ns ± 3% 446ns ± 0% ~ (p=0.238 n=10+9) TimeFormat 485ns ± 1% 483ns ± 1% ~ (p=0.073 n=10+10) Template 90.4ms ± 0% 90.7ms ± 0% +0.29% (p=0.000 n=8+10) GoParse 6.01ms ± 0% 6.03ms ± 0% +0.35% (p=0.000 n=10+10) BinaryTree17 11.7s ± 0% 11.7s ± 0% ~ (p=0.481 n=10+10) Revcomp 669ms ± 0% 669ms ± 0% ~ (p=0.315 n=10+10) Fannkuch11 3.40s ± 0% 3.37s ± 0% -0.92% (p=0.000 n=10+10) [Geo mean] 67.9µs 67.9µs +0.02% name old speed new speed delta RegexpMatchEasy0_32 128MB/s ± 0% 128MB/s ± 0% -0.08% (p=0.003 n=8+10) RegexpMatchEasy0_1K 1.75GB/s ± 0% 1.75GB/s ± 0% ~ (p=0.642 n=8+10) RegexpMatchEasy1_32 130MB/s ± 0% 130MB/s ± 0% ~ (p=0.690 n=10+9) RegexpMatchEasy1_1K 1.27GB/s ± 0% 1.27GB/s ± 0% ~ (p=0.661 n=10+9) RegexpMatchMedium_32 3.18MB/s ± 0% 3.18MB/s ± 0% ~ (all equal) RegexpMatchMedium_1K 19.7MB/s ± 0% 19.6MB/s ± 0% ~ (p=0.190 n=10+9) RegexpMatchHard_32 11.6MB/s ± 0% 11.6MB/s ± 1% ~ (p=0.669 n=10+10) RegexpMatchHard_1K 13.0MB/s ± 0% 13.0MB/s ± 0% ~ (p=0.718 n=9+9) Gzip 44.4MB/s ± 0% 44.5MB/s ± 0% +0.24% (p=0.000 n=10+10) JSONEncode 96.5MB/s ± 1% 96.1MB/s ± 1% ~ (p=0.065 n=9+10) JSONDecode 20.6MB/s ± 1% 20.7MB/s ± 1% +0.42% (p=0.041 n=10+10) GobDecode 60.6MB/s ± 1% 60.0MB/s ± 2% -0.92% (p=0.016 n=10+10) GobEncode 63.4MB/s ± 0% 63.6MB/s ± 0% ~ (p=0.055 n=10+10) Template 21.5MB/s ± 0% 21.4MB/s ± 0% -0.30% (p=0.000 n=9+10) GoParse 9.64MB/s ± 0% 9.61MB/s ± 0% -0.36% (p=0.000 n=10+10) Revcomp 380MB/s ± 0% 380MB/s ± 0% ~ (p=0.323 n=10+10) [Geo mean] 56.0MB/s 55.9MB/s -0.07% Change-Id: Ia732fa57fbcf4767d72382516d9f16705d177736 Reviewed-on: https://go-review.googlesource.com/96435 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Josh Bleecher Snyder authored
Moving tighten after lowering benefits from the removal of values by lowering and lowered CSE. It lets us make better decisions about which values are rematerializable and which generate flags. Empirically, it lowers stack usage (by avoiding spills) and generates slightly smaller and faster binaries. Fixes #19853 Fixes #21041 name old time/op new time/op delta Template 195ms ± 4% 193ms ± 4% -1.33% (p=0.000 n=92+97) Unicode 94.1ms ± 9% 92.5ms ± 8% -1.66% (p=0.002 n=97+95) GoTypes 572ms ± 5% 566ms ± 7% -0.92% (p=0.001 n=95+98) Compiler 2.56s ± 4% 2.52s ± 3% -1.41% (p=0.000 n=94+97) SSA 6.52s ± 2% 6.47s ± 3% -0.82% (p=0.000 n=96+94) Flate 117ms ± 5% 116ms ± 7% -0.72% (p=0.018 n=97+97) GoParser 148ms ± 6% 146ms ± 4% -0.97% (p=0.002 n=98+95) Reflect 370ms ± 7% 363ms ± 6% -1.79% (p=0.000 n=99+98) Tar 175ms ± 6% 173ms ± 6% -1.11% (p=0.001 n=94+95) XML 204ms ± 6% 201ms ± 5% -1.49% (p=0.000 n=97+96) [Geo mean] 363ms 359ms -1.22% name old user-time/op new user-time/op delta Template 251ms ± 5% 245ms ± 5% -2.40% (p=0.000 n=97+93) Unicode 131ms ±10% 128ms ± 9% -1.93% (p=0.001 n=100+99) GoTypes 760ms ± 4% 752ms ± 4% -0.96% (p=0.000 n=97+95) Compiler 3.51s ± 3% 3.48s ± 2% -1.04% (p=0.000 n=96+95) SSA 9.57s ± 4% 9.52s ± 2% -0.50% (p=0.004 n=97+96) Flate 149ms ± 6% 147ms ± 6% -1.46% (p=0.000 n=98+96) GoParser 184ms ± 5% 181ms ± 7% -1.84% (p=0.000 n=98+97) Reflect 469ms ± 6% 461ms ± 6% -1.69% (p=0.000 n=100+98) Tar 219ms ± 8% 217ms ± 7% -0.90% (p=0.035 n=96+96) XML 255ms ± 5% 251ms ± 6% -1.48% (p=0.000 n=98+98) [Geo mean] 476ms 469ms -1.42% name old alloc/op new alloc/op delta Template 37.8MB ± 0% 37.8MB ± 0% -0.17% (p=0.000 n=100+100) Unicode 28.8MB ± 0% 28.8MB ± 0% -0.02% (p=0.000 n=100+95) GoTypes 112MB ± 0% 112MB ± 0% -0.20% (p=0.000 n=100+97) Compiler 466MB ± 0% 464MB ± 0% -0.27% (p=0.000 n=100+100) SSA 1.49GB ± 0% 1.49GB ± 0% -0.08% (p=0.000 n=100+99) Flate 24.4MB ± 0% 24.3MB ± 0% -0.25% (p=0.000 n=98+99) GoParser 30.7MB ± 0% 30.6MB ± 0% -0.26% (p=0.000 n=99+100) Reflect 76.4MB ± 0% 76.4MB ± 0% ~ (p=0.253 n=100+100) Tar 38.9MB ± 0% 38.8MB ± 0% -0.20% (p=0.000 n=100+97) XML 41.5MB ± 0% 41.4MB ± 0% -0.19% (p=0.000 n=100+98) [Geo mean] 77.5MB 77.4MB -0.16% name old allocs/op new allocs/op delta Template 381k ± 0% 381k ± 0% -0.15% (p=0.000 n=100+100) Unicode 342k ± 0% 342k ± 0% -0.01% (p=0.000 n=100+98) GoTypes 1.19M ± 0% 1.18M ± 0% -0.24% (p=0.000 n=100+100) Compiler 4.52M ± 0% 4.50M ± 0% -0.29% (p=0.000 n=100+100) SSA 12.3M ± 0% 12.3M ± 0% -0.11% (p=0.000 n=100+100) Flate 234k ± 0% 234k ± 0% -0.26% (p=0.000 n=99+96) GoParser 318k ± 0% 317k ± 0% -0.21% (p=0.000 n=99+100) Reflect 974k ± 0% 974k ± 0% -0.03% (p=0.000 n=100+100) Tar 392k ± 0% 391k ± 0% -0.17% (p=0.000 n=100+99) XML 404k ± 0% 403k ± 0% -0.24% (p=0.000 n=99+99) [Geo mean] 794k 792k -0.17% name old object-bytes new object-bytes delta Template 393kB ± 0% 392kB ± 0% -0.19% (p=0.008 n=5+5) Unicode 207kB ± 0% 207kB ± 0% ~ (all equal) GoTypes 1.23MB ± 0% 1.22MB ± 0% -0.11% (p=0.008 n=5+5) Compiler 4.34MB ± 0% 4.33MB ± 0% -0.15% (p=0.008 n=5+5) SSA 9.85MB ± 0% 9.85MB ± 0% -0.07% (p=0.008 n=5+5) Flate 235kB ± 0% 234kB ± 0% -0.59% (p=0.008 n=5+5) GoParser 297kB ± 0% 296kB ± 0% -0.22% (p=0.008 n=5+5) Reflect 1.03MB ± 0% 1.03MB ± 0% -0.00% (p=0.008 n=5+5) Tar 332kB ± 0% 331kB ± 0% -0.15% (p=0.008 n=5+5) XML 413kB ± 0% 412kB ± 0% -0.19% (p=0.008 n=5+5) [Geo mean] 728kB 727kB -0.17% Change-Id: I9b5cdb668ed102a001897a05e833105acba220a2 Reviewed-on: https://go-review.googlesource.com/95995 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 26 Feb, 2018 14 commits
-
-
Keith Randall authored
Allow the compiler to generate code like CMPQ 16(AX), $7 It's tricky because it's difficult to spill such a comparison during flagalloc, because the same memory state might not be available at the restore locations. Solve this problem by decomposing the compare+load back into its parts if it needs to be spilled. The big win is that the write barrier test goes from: MOVL runtime.writeBarrier(SB), CX TESTL CX, CX JNE 60 to CMPL runtime.writeBarrier(SB), $0 JNE 59 It's one instruction and one byte smaller. Fixes #19485 Fixes #15245 Update #22460 Binaries are about 0.15% smaller. Change-Id: I4fd8d1111b6b9924d52f9a0901ca1b2e5cce0836 Reviewed-on: https://go-review.googlesource.com/86035Reviewed-by:
Ilya Tocar <ilya.tocar@intel.com>
-
Kunpei Sakai authored
Previously, finishcompare just used SetTypecheck, but this didn't recursively update any untyped bool typed subexpressions. This CL changes it to call typecheck, which correctly handles this. Also cleaned up outdated code for simplifying logic. Updates #23834 Change-Id: Ic7f92d2a77c2eb74024ee97815205371761c1c90 Reviewed-on: https://go-review.googlesource.com/97035Reviewed-by:
-
Kunpei Sakai authored
CL generated mechanically with github.com/mdempsky/unconvert. Also updated cmd/compile/internal/ssa/gen/*.rules manually. Change-Id: If721ef73cf0771ae83ce7e2d11623fc8d9155768 Reviewed-on: https://go-review.googlesource.com/97075Reviewed-by:
-
Ilya Tocar authored
Currently we generate NEGQ for DIV{Q,L,W}. By generating NEGL and NEGW, we will reduce code size, because NEGL doesn't require rex prefix. This also guarantees that upper 32 bits are zeroed, so we can revert CL 85736, and remove zero-extensions of DIVL results. Also adds test for redundant zero extend elimination. Fixes #23310 Change-Id: Ic58c3104c255a71371a06e09d10a975bbe5df587 Reviewed-on: https://go-review.googlesource.com/96815 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Yury Smolsky authored
FileHeader.Name also reflects this fact. Fixes #24018 Change-Id: Id0860a9b23c264ac4c6ddd65ba20e0f1f36e4865 Reviewed-on: https://go-review.googlesource.com/97057Reviewed-by:
-
motemen authored
The output of go with -x flag is formatted in a manner that file paths under current directory are modified to start with a dot (.), but when the directory path ends with a slash (/), the formatting goes wrong. Fixes #23982 Change-Id: I8f8d15dd52bee882a9c6357eb9eabdc3eaa887c3 GitHub-Last-Rev: 1493f38bafdf2c40f16392b794fd1a12eb12a151 GitHub-Pull-Request: golang/go#23985 Reviewed-on: https://go-review.googlesource.com/95755 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Hana Kim authored
This is for debugging the reported flaky tests. Update #24081 Change-Id: Ica046928f675d69e38251a47a6f225efedce920c Reviewed-on: https://go-review.googlesource.com/96855 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Heschi Kreinick <heschi@google.com>
-
Robert Griesemer authored
Change https://go-review.googlesource.com/79575 fixed the computation of recursive method sets by separating the method set computation from type computation. However, it didn't track an embedded method's scope and as a result, some methods' signatures were typed in the wrong context. This change tracks embedded methods together with their scope and uses that scope for the correct context setup when typing those method signatures. Fixes #23914. Change-Id: If3677dceddb43e9db2f9fb3c7a4a87d2531fbc2a Reviewed-on: https://go-review.googlesource.com/96376Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Ian Lance Taylor authored
Fixes #24115 Change-Id: I89d3d5a9c0916fd2e21fe5930549c4129de8ab48 Reviewed-on: https://go-review.googlesource.com/96983Reviewed-by:
Giovanni Bajo <rasky@develer.com> Reviewed-by:
-
Rens Rikkerink authored
When using the special import "C", the "cgo" build constraint is implied for the go file, potentially triggering unclear "undefined" error messages. Explicitly explain this in the documentation. Updates #24068 Change-Id: Ib656ceccd52c749ffe7fb2d3db9ac144f17abb32 GitHub-Last-Rev: 5a13f00a9b917e51246a5fbb642c4e9ed55aa21d GitHub-Pull-Request: golang/go#24072 Reviewed-on: https://go-review.googlesource.com/96655Reviewed-by:
-
Robert Griesemer authored
Extend cmd/internal/src.PosBase to track column information, and adjust the meaning of the PosBase position to mean the position at which the PosBase's relative (line, col) position starts (rather than indicating the position of the //line directive). Because this semantic change is made in the compiler's noder, it doesn't affect the logic of src.PosBase, only its test setup (where PosBases are constructed with corrected incomming positions). In short, src.PosBase now matches syntax.PosBase with respect to the semantics of src.PosBase.pos. For #22662. Change-Id: I5b1451cb88fff3f149920c2eec08b6167955ce27 Reviewed-on: https://go-review.googlesource.com/96535Reviewed-by:
-
Robert Griesemer authored
For line directives which have a line and a column number, an omitted filename means that the filename has not changed (per the issue below). For line directives w/o a column number, an omitted filename means the empty filename (to preserve the existing behavior). For #22662. Change-Id: I32cd9037550485da5445a34bb104706eccce1df1 Reviewed-on: https://go-review.googlesource.com/96476Reviewed-by:
-
Robert Griesemer authored
For dependency reasons, the data structure implementing source positions in the compiler is in cmd/internal/src. It contains highly compiler specific details (e.g. inlining index). This change introduces a parallel but simpler position representation, defined in the syntax package, which removes that package's dependency on cmd/internal/src, and also removes the need to deal with certain filename-specific operations (defined by the needs of the compiler) in the syntax package. As a result, the syntax package becomes again a compiler- independent, stand-alone package that at some point might replace (or augment) the existing top-level go/* syntax-related packages. Additionally, line directives that update column numbers are now correctly tracked through the syntax package, with additional tests added. (The respective changes also need to be made in cmd/internal/src; i.e., the compiler accepts but still ignores column numbers in line directives.) This change comes at the cost of a new position translation step, but that step is cheap because it only needs to do real work if the position base changed (i.e., if there is a new file, or new line directive). There is no noticeable impact on overall compiler performance measured with `compilebench -count 5 -alloc`: name old time/op new time/op delta Template 220ms ± 8% 228ms ±18% ~ (p=0.548 n=5+5) Unicode 119ms ±11% 113ms ± 5% ~ (p=0.056 n=5+5) GoTypes 684ms ± 6% 677ms ± 3% ~ (p=0.841 n=5+5) Compiler 3.19s ± 7% 3.01s ± 1% ~ (p=0.095 n=5+5) SSA 7.92s ± 8% 7.79s ± 1% ~ (p=0.690 n=5+5) Flate 141ms ± 7% 139ms ± 4% ~ (p=0.548 n=5+5) GoParser 173ms ±12% 171ms ± 4% ~ (p=1.000 n=5+5) Reflect 417ms ± 5% 411ms ± 3% ~ (p=0.548 n=5+5) Tar 205ms ± 5% 198ms ± 2% ~ (p=0.690 n=5+5) XML 232ms ± 4% 229ms ± 4% ~ (p=0.690 n=5+5) StdCmd 28.7s ± 5% 28.2s ± 2% ~ (p=0.421 n=5+5) name old user-time/op new user-time/op delta Template 269ms ± 4% 265ms ± 5% ~ (p=0.421 n=5+5) Unicode 153ms ± 7% 149ms ± 3% ~ (p=0.841 n=5+5) GoTypes 850ms ± 7% 862ms ± 4% ~ (p=0.841 n=5+5) Compiler 4.01s ± 5% 3.86s ± 0% ~ (p=0.190 n=5+4) SSA 10.9s ± 4% 10.8s ± 2% ~ (p=0.548 n=5+5) Flate 166ms ± 7% 167ms ± 6% ~ (p=1.000 n=5+5) GoParser 204ms ± 8% 206ms ± 7% ~ (p=0.841 n=5+5) Reflect 514ms ± 5% 508ms ± 4% ~ (p=0.548 n=5+5) Tar 245ms ± 6% 244ms ± 3% ~ (p=0.690 n=5+5) XML 280ms ± 4% 278ms ± 4% ~ (p=0.841 n=5+5) name old alloc/op new alloc/op delta Template 37.9MB ± 0% 37.9MB ± 0% ~ (p=0.841 n=5+5) Unicode 28.8MB ± 0% 28.8MB ± 0% ~ (p=0.841 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% ~ (p=0.151 n=5+5) Compiler 468MB ± 0% 468MB ± 0% -0.01% (p=0.032 n=5+5) SSA 1.50GB ± 0% 1.50GB ± 0% ~ (p=0.548 n=5+5) Flate 24.4MB ± 0% 24.4MB ± 0% ~ (p=1.000 n=5+5) GoParser 30.7MB ± 0% 30.7MB ± 0% ~ (p=1.000 n=5+5) Reflect 76.5MB ± 0% 76.5MB ± 0% ~ (p=0.548 n=5+5) Tar 38.9MB ± 0% 38.9MB ± 0% ~ (p=0.222 n=5+5) XML 41.6MB ± 0% 41.6MB ± 0% ~ (p=0.548 n=5+5) name old allocs/op new allocs/op delta Template 382k ± 0% 382k ± 0% +0.01% (p=0.008 n=5+5) Unicode 343k ± 0% 343k ± 0% ~ (p=0.841 n=5+5) GoTypes 1.19M ± 0% 1.19M ± 0% +0.01% (p=0.008 n=5+5) Compiler 4.53M ± 0% 4.53M ± 0% +0.03% (p=0.008 n=5+5) SSA 12.4M ± 0% 12.4M ± 0% +0.00% (p=0.008 n=5+5) Flate 235k ± 0% 235k ± 0% ~ (p=0.079 n=5+5) GoParser 318k ± 0% 318k ± 0% ~ (p=0.730 n=5+5) Reflect 978k ± 0% 978k ± 0% ~ (p=1.000 n=5+5) Tar 393k ± 0% 393k ± 0% ~ (p=0.056 n=5+5) XML 405k ± 0% 405k ± 0% ~ (p=0.548 n=5+5) name old text-bytes new text-bytes delta HelloSize 672kB ± 0% 672kB ± 0% ~ (all equal) CmdGoSize 7.12MB ± 0% 7.12MB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 133kB ± 0% 133kB ± 0% ~ (all equal) CmdGoSize 390kB ± 0% 390kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.07MB ± 0% 1.07MB ± 0% ~ (all equal) CmdGoSize 11.2MB ± 0% 11.2MB ± 0% ~ (all equal) Passes toolstash compare. For #22662. Change-Id: I19edb53dd9675af57f7122cb7dba2a6d8bdcc3da Reviewed-on: https://go-review.googlesource.com/94515Reviewed-by:
-
Brad Fitzpatrick authored
Despite the existing test that locks in the allocation behavior, people really want a benchmark. So: BenchmarkBuildString_Builder/1Write_NoGrow-4 20000000 60.4 ns/op 48 B/op 1 allocs/op BenchmarkBuildString_Builder/3Write_NoGrow-4 10000000 230 ns/op 336 B/op 3 allocs/op BenchmarkBuildString_Builder/3Write_Grow-4 20000000 102 ns/op 112 B/op 1 allocs/op BenchmarkBuildString_ByteBuffer/1Write_NoGrow-4 10000000 125 ns/op 160 B/op 2 allocs/op BenchmarkBuildString_ByteBuffer/3Write_NoGrow-4 5000000 339 ns/op 400 B/op 3 allocs/op BenchmarkBuildString_ByteBuffer/3Write_Grow-4 5000000 316 ns/op 336 B/op 3 allocs/op I don't think these allocate-as-fast-as-you-can benchmarks are very interesting because they're effectively just GC benchmarks, but sure. If one wants to see that there's 1 fewer allocation, there it is. The ns/op and B/op numbers will change as the built string size changes. Updates #18990 Change-Id: Ifccf535bd396217434a0e6989e195105f90132ae Reviewed-on: https://go-review.googlesource.com/96980 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
