- 22 Sep, 2017 18 commits
-
-
Austin Clements authored
panicwrap currently uses runtime.Callers and runtime.CallersFrames to find the name of its caller. Simplify this by using getcallerpc. This will be important for #16723, since to fix that we're going to make CallersFrames skip the wrapper method, which is exactly what panicwrap needs to see. Change-Id: Icb0776d399966e31595f3ee44f980290827e32a6 Reviewed-on: https://go-review.googlesource.com/45411 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
Now that getcallerpc is a compiler intrinsic on x86 and non-x86 platforms don't need the argument, we can drop it. Sadly, this doesn't let us remove any dummy arguments since all of those cases also use getcallersp, which still takes the argument pointer, but this is at least an improvement. Change-Id: I9c34a41cf2c18cba57f59938390bf9491efb22d2 Reviewed-on: https://go-review.googlesource.com/65474 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
Ian Lance Taylor authored
CL 31148 added code to protect again simultaneous calls to Close and Wait when using the standard input pipe, to fix the race condition described in issue #9307. That issue is a special case of the race between Close and Write described by issue #7970. Since issue #7970 was not fixed, CL 31148 fixed the problem specific to os/exec. Since then, issue #7970 has been fixed, so the specific fix in os/exec is no longer necessary. Remove it, effectively reverting CL 31148 and followup CL 33298. Updates #7970 Updates #9307 Updates #17647 Change-Id: Ic0b62569cb0aba44b32153cf5f9632bd1f1b411a Reviewed-on: https://go-review.googlesource.com/65490 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
Miguel Bernabeu <miguelbernadi@gmail.com> Reviewed-by:
Russ Cox <rsc@golang.org> Reviewed-by:
Joe Tsai <joetsai@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
This no longer appears to be reproducible on windows/386. Try putting it back and we'll see if the builders still don't like it. Fixes #19319. Change-Id: Ia47b034e18d0a5a1951125c00542b021aacd5e8d Reviewed-on: https://go-review.googlesource.com/47936 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
David Chase authored
First step towards removing the mandatory argument for getcallerpc, which solves certain problems for the runtime. This might also slightly improve performance. Intrinsic enabled on 386, amd64, amd64p32, runtime asm implementation removed on those architectures. Now-superfluous argument remains in getcallerpc signature (for a future CL; non-386/amd64 asm funcs ignore it). Added getcallerpc to the "not a real function" test in dcl.go, that story is a little odd with respect to unexported functions but that is not this CL. Fixes #17327. Change-Id: I5df1ad91f27ee9ac1f0dd88fa48f1329d6306c3e Reviewed-on: https://go-review.googlesource.com/31851 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Ian Lance Taylor authored
For a trivial benchmark with a do-nothing cgo call: name old time/op new time/op delta Call-4 64.5ns ± 7% 63.0ns ± 6% -2.25% (p=0.027 n=20+16) Because Windows uses the cgocall mechanism to make system calls, and passes arguments in a struct held in the m, we need to do the lockOSThread/unlockOSThread in that code. Because deferreturn was getting a nosplit stack overflow error, change it to avoid calling typedmemmove. Updates #21827. Change-Id: I9b1d61434c44faeb29805b46b409c812c9acadc2 Reviewed-on: https://go-review.googlesource.com/64070 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Alessandro Arzilli authored
Updates #14517 Change-Id: I23ef88e71c89da12dffcadf5562ea2d7557b62cf Reviewed-on: https://go-review.googlesource.com/61019Reviewed-by:
-
Daniel Martí authored
This is based from a list that Keith Randall provided in mid-2016. These are all funcs that, at the time, were important and small enough that they should be clearly inlined. The runtime has changed a bit since then. Ctz16 and Ctz8 were removed, so don't add them. stringtoslicebytetmp was moved to the backend, so it's no longer a Go function. And itabhash was moved to itabHashFunc. The only other outlier is adjustctxt, which is not inlineable at the moment. I've added a TODO and will address it myself in a separate commit. While at it, error if any funcs in the input table are duplicated. They're never useful and typos could lead to unintentionally thinking a function is inlineable when it actually isn't. And, since the lists are getting long, start sorting alphabetically. Finally, rotl_31 is only defined on 64-bit architectures, and the added runtime/internal/sys funcs are assembly on 386 and thus non-inlineable in that case. Updates #21851. Change-Id: Ib99ab53d777860270e8fd4aefc41adb448f13662 Reviewed-on: https://go-review.googlesource.com/65351 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Keith Randall <khr@golang.org>
-
Daniel Martí authored
The first just falls through, and the default case does nothing. They can be deleted. Change-Id: I82ab1ce3acde0b8423334cfbf35f9e0c806cd494 Reviewed-on: https://go-review.googlesource.com/65410Reviewed-by:
-
Daniel Martí authored
Rework the logic to remove them. These were the low hanging fruit, with labels that were used only once and logic that was fairly straightforward. Change-Id: I02a01c59c247b8b2972d8d73ff23f96f271de038 Reviewed-on: https://go-review.googlesource.com/63410 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
It's only used/needed by SubstAny. CL prepared with gorename. Change-Id: I243138f9dcc4e6af9b81a7746414e6d7b3ba10a2 Reviewed-on: https://go-review.googlesource.com/65311Reviewed-by:
-
David du Colombier authored
CL 60871 added TestSparseFiles. This test is succeeding on Plan 9 when executed on the ramfs file system, but is failing when executed on the Fossil file system. This may be due to an issue in the handling of sparse files in the Fossil file system on Plan 9 that should be investigated. Updates #21977. Change-Id: I177afff519b862a5c548e094203c219504852006 Reviewed-on: https://go-review.googlesource.com/65352Reviewed-by:
-
Tobias Klauser authored
Change-Id: I6d8c8ca0dee972cabfcc95fda23aea25692633a5 Reviewed-on: https://go-review.googlesource.com/65350Reviewed-by:
-
Daniel Martí authored
Do the low-hanging fruit - tiny Less functions that are used exactly once. This reduces the amount of code and puts the logic in a single place. Change-Id: I9d4544cd68de5a95e55019bdad1fca0a1dbfae9c Reviewed-on: https://go-review.googlesource.com/63171 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Carlos Eduardo Seo authored
Analog to the runtime package, syscall.Select should be using newselect instead of select. This change addresses this problem and regenerates zsyscall_linux_* for ppc64 and ppc64le. Updates #21946 Change-Id: I5dc3bf9e7f0b1172d6cce30ddf3bb1e3c95ec8e9 Reviewed-on: https://go-review.googlesource.com/65090 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Lynn Boger <laboger@linux.vnet.ibm.com>
-
Michael Munday authored
Change-Id: Ia4b49736d3b33cddf58905c6b19febbca45b2ad2 Reviewed-on: https://go-review.googlesource.com/64270Reviewed-by:
-
Daniel Martí authored
If we use -gcflags='-m -m', the compiler should give us a reason why a func couldn't be inlined. Add the extra -m necessary for that extra info and use it to give better test failures. For example, for the func in the TODO: --- FAIL: TestIntendedInlining (1.53s) inl_test.go:104: runtime.nextFreeFast was not inlined: function too complex We might increase the number of -m flags to get more information at some later point, such as getting details on how close the func was to the inlining budget. Also started using regexes, as the output parsing is getting a bit too complex for manual string handling. While at it, also refactored the test to not buffer the entire output into memory. This is fine in practice, but it won't scale well as we add more packages or we depend more on the compiler's debugging output. For example, "go build -a -gcflags='-m -m' std" prints nearly 40MB of plaintext - and we only need to see the output line by line anyway. Updates #21851. Change-Id: I00986ff360eb56e4e9737b65a6be749ef8540643 Reviewed-on: https://go-review.googlesource.com/63810 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Marvin Stenger authored
The TODO is no longer needed as it was solved by a previous CL. See https://go-review.googlesource.com/14995. Change-Id: If62d1b296f35758ad3d18d28c8fbb95e797f4464 Reviewed-on: https://go-review.googlesource.com/65232Reviewed-by:
Robert Griesemer <gri@golang.org>
-
- 21 Sep, 2017 8 commits
-
-
Joe Tsai authored
The test for hole-detection is heavily dependent on whether the OS and underlying FS provides support for it. Even on Linux, which has support for SEEK_HOLE and SEEK_DATA, the underlying filesystem may not have support for it. In order to avoid an ever-changing game of whack-a-mole, we whitelist the specific builders that we expect the test to pass on. Updates #21964 Change-Id: I7334e8532c96cc346ea83aabbb81b719685ad7e5 Reviewed-on: https://go-review.googlesource.com/65270 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by:
-
Hiroshi Ioka authored
After https://golang.org/cl/64793, we started to include Mach-O object files which don't have symbol table into cgo archive. However, toolchains didn't handle those files yet. Fixes #21959 Change-Id: Ibb2f6492f1fa59368f2dfd4cff19783997539875 Reviewed-on: https://go-review.googlesource.com/65170Reviewed-by:
-
Gabriel Aszalos authored
Some methods that were used to implement various `io` interfaces in the Reader were documented, whereas others were not. This change adds documentation to all the missing methods used to implement these interfaces. Change-Id: I2dac6e328542de3cd87e89510651cd6ba74a7b7d Reviewed-on: https://go-review.googlesource.com/65231Reviewed-by:
-
Joe Tsai authored
On most Unix OSes, lseek reports EINVAL when lacking SEEK_HOLE support. However, there are reports that ENOTTY is reported instead. Rather than tracking down every possible errno that may be used to represent "not supported", just treat any non-nil error as meaning that there is no support. This is the same strategy taken by the GNU and BSD tar tools. Fixes #21958 Change-Id: Iae68afdc934042f52fa914fca45f0ca89220c383 Reviewed-on: https://go-review.googlesource.com/65191 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ben Shi authored
BFX&BFXU were introduced in ARMv6T2. A single BFX or BFXU is more efficiently than a pair of left-shift/right-shift in bit field extraction. This patch implements this optimization. And the benchmark tests show big improvement in special cases and little change in total. 1. There is big improvement in a special test case. name old time/op new time/op delta BFX-4 665µs ± 1% 595µs ± 0% -10.61% (p=0.000 n=20+20) (The test case: https://github.com/benshi001/ugo1/blob/master/bfx_test.go) 2. The compilecmp benchmark shows no regression. name old time/op new time/op delta Template 2.33s ± 2% 2.34s ± 2% ~ (p=0.356 n=9+10) Unicode 1.32s ± 2% 1.30s ± 2% ~ (p=0.139 n=9+8) GoTypes 7.77s ± 1% 7.76s ± 1% ~ (p=0.780 n=10+9) Compiler 37.3s ± 1% 37.1s ± 1% ~ (p=0.211 n=10+9) SSA 84.3s ± 2% 84.3s ± 2% ~ (p=0.842 n=10+9) Flate 1.45s ± 1% 1.45s ± 3% ~ (p=0.853 n=10+10) GoParser 1.83s ± 2% 1.83s ± 2% ~ (p=0.739 n=10+10) Reflect 5.08s ± 2% 5.09s ± 2% ~ (p=0.720 n=9+10) Tar 2.44s ± 1% 2.44s ± 2% ~ (p=0.684 n=10+10) XML 2.62s ± 2% 2.62s ± 2% ~ (p=0.529 n=10+10) [Geo mean] 4.80s 4.79s -0.06% name old user-time/op new user-time/op delta Template 2.76s ± 2% 2.75s ± 3% ~ (p=0.893 n=10+10) Unicode 1.63s ± 1% 1.60s ± 1% -2.07% (p=0.000 n=8+9) GoTypes 9.54s ± 1% 9.52s ± 1% ~ (p=0.215 n=10+10) Compiler 46.0s ± 1% 46.0s ± 1% ~ (p=0.853 n=10+10) SSA 110s ± 1% 110s ± 1% ~ (p=0.838 n=10+10) Flate 1.69s ± 3% 1.69s ± 5% ~ (p=0.957 n=10+10) GoParser 2.15s ± 2% 2.15s ± 2% ~ (p=0.749 n=10+10) Reflect 6.03s ± 1% 5.99s ± 2% ~ (p=0.060 n=9+10) Tar 3.02s ± 2% 2.99s ± 2% ~ (p=0.214 n=10+10) XML 3.10s ± 2% 3.08s ± 2% ~ (p=0.732 n=9+10) [Geo mean] 5.82s 5.79s -0.41% name old text-bytes new text-bytes delta HelloSize 589kB ± 0% 589kB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 5.46kB ± 0% 5.46kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 76.9kB ± 0% 76.9kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.03MB ± 0% 1.03MB ± 0% ~ (all equal) 3. The go1 benchmark shows little change in total. (excluding noise) name old time/op new time/op delta BinaryTree17-4 41.5s ± 1% 41.6s ± 1% ~ (p=0.373 n=30+26) Fannkuch11-4 23.6s ± 1% 23.6s ± 1% +0.28% (p=0.003 n=29+30) FmtFprintfEmpty-4 826ns ± 1% 827ns ± 1% ~ (p=0.155 n=30+30) FmtFprintfString-4 1.35µs ± 1% 1.35µs ± 1% ~ (p=0.499 n=30+30) FmtFprintfInt-4 1.43µs ± 1% 1.41µs ± 1% -1.19% (p=0.000 n=30+30) FmtFprintfIntInt-4 2.15µs ± 1% 2.11µs ± 1% -1.78% (p=0.000 n=30+30) FmtFprintfPrefixedInt-4 2.21µs ± 1% 2.21µs ± 1% ~ (p=0.881 n=30+30) FmtFprintfFloat-4 4.41µs ± 1% 4.44µs ± 0% +0.64% (p=0.000 n=30+30) FmtManyArgs-4 8.06µs ± 1% 8.06µs ± 0% ~ (p=0.871 n=30+30) GobDecode-4 103ms ± 1% 104ms ± 2% +0.54% (p=0.013 n=28+29) GobEncode-4 92.4ms ± 1% 92.6ms ± 1% ~ (p=0.447 n=30+29) Gzip-4 4.17s ± 1% 4.06s ± 1% -2.56% (p=0.000 n=29+30) Gunzip-4 603ms ± 1% 602ms ± 1% ~ (p=0.423 n=30+30) HTTPClientServer-4 688µs ± 2% 674µs ± 3% -2.09% (p=0.000 n=29+30) JSONEncode-4 237ms ± 1% 237ms ± 1% ~ (p=0.061 n=29+30) JSONDecode-4 907ms ± 1% 910ms ± 1% ~ (p=0.061 n=30+30) Mandelbrot200-4 41.7ms ± 0% 41.7ms ± 0% +0.19% (p=0.000 n=24+20) GoParse-4 45.7ms ± 2% 45.5ms ± 2% -0.29% (p=0.005 n=30+30) RegexpMatchEasy0_32-4 1.27µs ± 0% 1.27µs ± 0% +0.12% (p=0.031 n=30+30) RegexpMatchEasy0_1K-4 7.77µs ± 4% 7.73µs ± 3% ~ (p=0.169 n=30+30) RegexpMatchEasy1_32-4 1.29µs ± 1% 1.29µs ± 1% ~ (p=0.126 n=30+30) RegexpMatchEasy1_1K-4 10.4µs ± 3% 10.3µs ± 2% -1.32% (p=0.004 n=30+29) RegexpMatchMedium_32-4 2.06µs ± 0% 2.06µs ± 0% ~ (p=0.071 n=30+30) RegexpMatchMedium_1K-4 531µs ± 1% 530µs ± 0% ~ (p=0.121 n=30+23) RegexpMatchHard_32-4 28.7µs ± 1% 28.6µs ± 1% -0.21% (p=0.001 n=30+27) RegexpMatchHard_1K-4 860µs ± 1% 857µs ± 1% ~ (p=0.105 n=30+27) Revcomp-4 67.3ms ± 2% 67.3ms ± 2% ~ (p=0.805 n=29+29) Template-4 1.08s ± 1% 1.08s ± 1% ~ (p=0.260 n=30+30) TimeParse-4 7.04µs ± 0% 7.04µs ± 0% ~ (p=0.315 n=30+30) TimeFormat-4 13.2µs ± 1% 13.2µs ± 1% ~ (p=0.077 n=30+30) [Geo mean] 715µs 713µs -0.30% name old speed new speed delta GobDecode-4 7.42MB/s ± 1% 7.38MB/s ± 2% -0.54% (p=0.011 n=28+29) GobEncode-4 8.30MB/s ± 1% 8.29MB/s ± 1% ~ (p=0.484 n=30+29) Gzip-4 4.65MB/s ± 2% 4.78MB/s ± 1% +2.73% (p=0.000 n=30+30) Gunzip-4 32.2MB/s ± 1% 32.2MB/s ± 1% ~ (p=0.357 n=30+30) JSONEncode-4 8.18MB/s ± 1% 8.19MB/s ± 1% ~ (p=0.052 n=29+30) JSONDecode-4 2.14MB/s ± 1% 2.13MB/s ± 1% ~ (p=0.074 n=30+29) GoParse-4 1.27MB/s ± 1% 1.27MB/s ± 2% ~ (p=0.618 n=24+30) RegexpMatchEasy0_32-4 25.2MB/s ± 0% 25.2MB/s ± 0% -0.12% (p=0.031 n=30+30) RegexpMatchEasy0_1K-4 132MB/s ± 5% 132MB/s ± 2% ~ (p=0.171 n=30+30) RegexpMatchEasy1_32-4 24.8MB/s ± 1% 24.9MB/s ± 1% ~ (p=0.106 n=30+30) RegexpMatchEasy1_1K-4 98.4MB/s ± 3% 99.6MB/s ± 4% +1.19% (p=0.011 n=30+30) RegexpMatchMedium_32-4 483kB/s ± 1% 484kB/s ± 1% ~ (p=0.426 n=30+30) RegexpMatchMedium_1K-4 1.93MB/s ± 1% 1.93MB/s ± 0% ~ (p=0.157 n=30+17) RegexpMatchHard_32-4 1.12MB/s ± 1% 1.12MB/s ± 0% +0.33% (p=0.001 n=30+24) RegexpMatchHard_1K-4 1.19MB/s ± 1% 1.19MB/s ± 1% ~ (p=0.290 n=30+30) Revcomp-4 37.8MB/s ± 2% 37.8MB/s ± 1% ~ (p=0.815 n=29+29) Template-4 1.80MB/s ± 1% 1.80MB/s ± 1% ~ (p=0.586 n=30+30) [Geo mean] 6.80MB/s 6.81MB/s +0.25% fixes #20966 Change-Id: Idb5567bbe988c875315b8c98c128957cd474ccc5 Reviewed-on: https://go-review.googlesource.com/64950Reviewed-by:
Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com>
-
Michael Darakananda authored
Docs of WithDeadline refers to variable "d" which does not exist in the docs. This commit renames the time argument to "d" to make the doc work. Change-Id: Ifd2c1be7d2e3f7dfb21cd9bb8ff7fc5039c8d3bd Reviewed-on: https://go-review.googlesource.com/65130 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Hiroshi Ioka authored
This CL also make cmd/nm accept PE object file. Fixes #21706 Change-Id: I4a528b7d53da1082e61523ebeba02c4c514a43a7 Reviewed-on: https://go-review.googlesource.com/64890 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Avelino authored
Change-Id: I33284d3154db43b2b89418c5076df79407e7cf41 Reviewed-on: https://go-review.googlesource.com/60931 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 20 Sep, 2017 14 commits
-
-
Cherry Zhang authored
Use a counter, instead of a loop, to see whether there are more writebarrier ops in the current block that need to be rewritten. No visible change in normal compiler speed benchmarks. Passes toolstash -cmp on std cmd. Fixes #20416. Change-Id: Ifbbde23611cd668c35b8a4a3e9a92726bfe19956 Reviewed-on: https://go-review.googlesource.com/60310Reviewed-by:
-
Matthew Dempsky authored
onebitwalktype1 no longer appears to be a bottleneck for the mentioned test case. In fact, we appear to compile it significantly faster now than Go 1.4 did (~1.8s vs ~3s). Fixes #21951. Change-Id: I315313e906092a7d6ff4ff60a918d80a4cff7a7f Reviewed-on: https://go-review.googlesource.com/65110Reviewed-by:
-
Joe Tsai authored
To support the detection and creation of sparse files, add two new methods: func Header.DetectSparseHoles(*os.File) error func Header.PunchSparseHoles(*os.File) error DetectSparseHoles is intended to be used after FileInfoHeader prior to serializing the Header with WriteHeader. For each OS, it uses specialized logic to detect the location of sparse holes. On most Unix systems, it uses SEEK_HOLE and SEEK_DATA to query for the holes. On Windows, it uses a specialized the FSCTL_QUERY_ALLOCATED_RANGES syscall to query for all the holes. PunchSparseHoles is intended to be used after Reader.Next prior to populating the file with Reader.WriteTo. On Windows, this uses the FSCTL_SET_ZERO_DATA syscall. On other operating systems it simply truncates the file to the end-offset of SparseHoles. DetectSparseHoles and PunchSparseHoles are added as methods on Header because they are heavily tied to the operating system, for which there is already an existing precedence for (since FileInfoHeader makes uses of OS-specific details). Fixes #13548 Change-Id: I98a321dd1ce0165f3d143d4edadfda5e7db67746 Reviewed-on: https://go-review.googlesource.com/60871 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Agniva De Sarker authored
- using FMA and AVX instructions if available to speed-up Exp calculation on amd64 - using a data table instead of #define'ed constants because these instructions do not support loading floating point immediates. One has to use a memory operand / register. - Benchmark results on Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz: Original vs New (non-FMA path) name old time/op new time/op delta Exp 16.0ns ± 1% 16.1ns ± 3% ~ (p=0.308 n=9+10) Original vs New (FMA path) name old time/op new time/op delta Exp 16.0ns ± 1% 13.7ns ± 2% -14.80% (p=0.000 n=9+10) Change-Id: I3d8986925d82b39b95ee979ae06f59d7e591d02e Reviewed-on: https://go-review.googlesource.com/62590Reviewed-by:
Ilya Tocar <ilya.tocar@intel.com> Reviewed-by:
-
Ilya Tocar authored
When debugging inliner with -m -m print cost of complex functions, instead of simple "function too complex". This helps to understand, how close to inlining is this particular function. Change-Id: I6871f69b5b914d23fd0b43a24d7c6fc928f4b716 Reviewed-on: https://go-review.googlesource.com/63330 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> Reviewed-by:
-
Ian Lance Taylor authored
https://golang.org/cl/5822049 introduced the idea of linking together all the cgo objects with -r, while also linking against -lgcc. This was to fix http://golang.org/issue/3261: cgo code that requires libgcc would break when using internal linking. This approach introduced https://golang.org/issue/9510: multiple different cgo packages could include the same libgcc object, leading to a multiple definition error during the final link. That problem was fixed by https://golang.org/cl/16741, as modified by https://golang.org/cl/16993, which did the link against libgcc only during the final link. After https://golang.org/cl/16741, and, on Windows, the later https://golang.org/cl/26670, ld -r no longer does anything useful. So, remove it. Doing this revealed that running ld -r on Darwin simplifies some relocs by making them specific to a symbol rather than a section. Correct the handling of unsigned relocations in internal linking mode by offsetting by the symbol value. This only really comes up when using the internal linker with C code that initializes a variable to the address of a local constant, such as a C string (as in const char *s = "str";). This change does not affect the normal case of external linking, where the Add field is ignored. The test case is misc/cgo/test/issue6612.go in internal linking mode. The cmd/internal/goobj test can now see an external object with no symbol table; fix it to not crash in that case. Change-Id: I15e5b7b5a8f48136bc14bf4e1c4c473d5eb58062 Reviewed-on: https://go-review.googlesource.com/64793 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ilya Tocar authored
https://golang.org/cl/22598 made nextFreeFast inlinable. But during https://golang.org/cl/63611 it was discovered, that it is no longer inlinable. Reduce number of statements below inlining threshold to make it inlinable again. Also update tests, to prevent regressions. Doesn't reduce readability. Change-Id: Ia672784dd48ed3b1ab46e390132f1094fe453de5 Reviewed-on: https://go-review.googlesource.com/65030 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Michael Munday authored
When rewriting loads and stores accessing global variables to use the GOT we were making use of REGTMP (R10). Unfortunately loads and stores with large offsets (larger than 20-bits) were also using REGTMP, causing it to be clobbered and subsequently a segmentation fault. This can be fixed by using REGTMP2 (R11) for the rewrite. This is fine because REGTMP2 only has a couple of uses in the assembler (division, high multiplication and storage-to-storage instructions). We didn't use REGTMP2 originally because it used to be used more frequently, in particular for stores of constants to memory. However we have now eliminated those uses. This was found while writing a test case for CL 63030. That test case is included in this CL. Change-Id: I13956f1f3ca258a7c8a7ff0a7570d2848adf7f68 Reviewed-on: https://go-review.googlesource.com/65011Reviewed-by:
-
Matthew Dempsky authored
No functional change; just making the code slightly more idiomatic. Passes toolstash-check. Change-Id: I66d14a8410bbecf260d0ea5683564aa413ce5747 Reviewed-on: https://go-review.googlesource.com/65070 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Matthew Dempsky authored
The existing logic tried to advance the offset for each variable's width, but then tried to undo this logic with the array and struct handling code. It can all be much simpler by only worrying about computing offsets within the array and struct code. While here, include a short-circuit for zero-width arrays to fix a pedantic compiler failure case. Passes toolstash-check. Fixes #20739. Change-Id: I98af9bb512a33e3efe82b8bf1803199edb480640 Reviewed-on: https://go-review.googlesource.com/64471 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
The previous code seems to have an off-by-1 in it somewhere, the consequence being that we didn't properly preserve all of the old buffer contents that we intended to. After spending a while looking at the existing window-shifting logic, I wasn't able to understand exactly how it was supposed to work or where the issue was, so I rewrote it to be (at least IMO) more obviously correct. Fixes #21938. Change-Id: I1ed7bbc1e1751a52ab5f7cf0411ae289586dc345 Reviewed-on: https://go-review.googlesource.com/64830 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
We used to backup symbol declarations using complete Syms, but this was unnecessary: very few of Sym's fields were actually needed. Also, to restore a symbol, we had to re-Lookup the Sym in its Pkg. By introducing a new dedicated dsym type for this purpose, we can address both of these deficiencies. Passes toolstash-check. Change-Id: I39f3d672b301f84a3a62b9b34b4b2770cb25df79 Reviewed-on: https://go-review.googlesource.com/64811 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Kunpei Sakai authored
See https://go-review.googlesource.com/c/go/+/59850 Change-Id: I9f0b6bc009eae86cbbdb56562ee4eb8d5eef653e Reviewed-on: https://go-review.googlesource.com/61230Reviewed-by:
Tom Bergan <tombergan@google.com>
-
Michael Munday authored
Rematerializable ops can be inserted after the flagalloc phase, they must therefore not clobber flags. This CL adds a check to ensure this doesn't happen and fixes the instances where it does currently. amd64: ADDQconst and ADDLconst were recently changed to be rematerializable in CL 54393 (only in tip, not 1.9). That change has been reverted. s390x: MOVDaddr could clobber flags when using dynamic linking due to a ADD with immediate instruction. Change the code generation to use LA/LAY instead. Fixes #21080. Change-Id: Ia85c882afa2a820a309e93775354b3169ec6d034 Reviewed-on: https://go-review.googlesource.com/63030 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
