- 18 Aug, 2017 7 commits
-
-
Brian Kessler authored
Updates #13745 Recognize z.Mul(x, x) as squaring for Floats and use the internal z.sqr(x) method for nat on the mantissa. Change-Id: I0f792157bad93a13cae1aecc4c10bd20c6397693 Reviewed-on: https://go-review.googlesource.com/56774Reviewed-by:
Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brian Kessler authored
updates #13745 A squared rational is always positive and can not be reduced since the numerator and denominator had no previous common factors. The nat multiplication can be performed using the internal sqr method. Change-Id: I558f5b38e379bfd26ff163c9489006d7e5a9cfaa Reviewed-on: https://go-review.googlesource.com/56776Reviewed-by:
-
Martin Möhrmann authored
Change-Id: I1929ea7e4ed88631ef729472ffe474016efec3e8 Reviewed-on: https://go-review.googlesource.com/56370Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Daniel Martí authored
Found with mvdan.cc/unindent. Prioritized the ones with the biggest wins for now. Change-Id: I2b032e45cdd559fc9ed5b1ee4c4de42c4c92e07b Reviewed-on: https://go-review.googlesource.com/56470 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alex Brainman authored
Another attempt to fix build Change-Id: I26137c115ad4b5f5a69801ed981c146adf6e824c Reviewed-on: https://go-review.googlesource.com/56750Reviewed-by:
-
Alex Brainman authored
Hopefully fixes build. Change-Id: If0629b95b923a65e4507073cf7aa44a5e178fc0f Reviewed-on: https://go-review.googlesource.com/56711Reviewed-by:
-
Christopher Nelson authored
Change-Id: Id717054cb3c4537452f8ff848445b0c20196a373 Reviewed-on: https://go-review.googlesource.com/33579 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Alex Brainman <alex.brainman@gmail.com>
-
- 17 Aug, 2017 18 commits
-
-
Hiroshi Ioka authored
Updates #21487 Change-Id: Ia549a87a8a305cc80da11ea9bd904402f1a14689 Reviewed-on: https://go-review.googlesource.com/56321Reviewed-by:
-
Hiroshi Ioka authored
Change-Id: I7f7b1e7ef832d53a93562b08ae914d023247c2c0 Reviewed-on: https://go-review.googlesource.com/56312 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
Just to get rid of lots of .Name() stutter in printf calls. Change-Id: I86cf00b3f7b2172387a1c6a7f189c1897fab6300 Reviewed-on: https://go-review.googlesource.com/56630 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
Martin Möhrmann authored
Use mallogc instead of newarray to save some overhead since makechan already checks for _MaxMem constraints. Flattens the if else construct that determines if buf and hchan struct should be allocated in one mallocgc call and where buf should point to. Uses maxSliceCap to avoid divisions similar to makeslice. name old time/op new time/op delta MakeChan/Byte 82.0ns ± 8% 81.4ns ± 7% ~ (p=0.643 n=10+10) MakeChan/Int 97.9ns ± 2% 96.6ns ± 2% -1.40% (p=0.009 n=10+10) MakeChan/Ptr 128ns ± 3% 120ns ± 1% -6.63% (p=0.000 n=10+10) MakeChan/Struct/0 66.7ns ± 4% 66.4ns ± 2% ~ (p=0.697 n=10+10) MakeChan/Struct/32 136ns ± 1% 130ns ± 0% -4.42% (p=0.000 n=10+10) MakeChan/Struct/40 150ns ± 1% 150ns ± 1% ~ (p=0.725 n=10+10) Change-Id: Ibb5675d0843a072aae2bfa58ecd39cf4cd926533 Reviewed-on: https://go-review.googlesource.com/55132 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Martin Möhrmann authored
Stack allocated hmap structs are explicitly zeroed before being passed by pointer to makemap. Heap allocated hmap structs are created with newobject which also zeroes on allocation. Therefore, setting the hmap fields to 0 or nil is redundant since they will have been zeroed when hmap was allocated. Change-Id: I5fc55b75e9dc5ba69f5e3588d6c746f53b45ba66 Reviewed-on: https://go-review.googlesource.com/56291Reviewed-by:
-
Kyle Shannon authored
Fix a missed change from: https://golang.org/cl/56190 pointed out on the fossil mailing list shortly after submission of the change mentioned above. See: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg25736.html This change adds fossil to the general regular expression that is checked last in the import path check. For #10010 Change-Id: I6b711cdb1a8d4d767f61e1e28dc29dce529e0fad Reviewed-on: https://go-review.googlesource.com/56491Reviewed-by:
Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
-
Bryan C. Mills authored
We're making two extra round-trips to C to malloc and free strings that originate in Go and don't escape. Skip those round-trips by allocating null-terminated slices in Go memory instead. Change-Id: I9e4c5ad999a7924ba50b82293c52073ec75518be Reviewed-on: https://go-review.googlesource.com/56530 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
Updates #21253 Change-Id: Iece71a27207b578618cafb378dac2362517363d0 Reviewed-on: https://go-review.googlesource.com/52531 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Than McIntosh <thanm@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Ilya Tocar authored
We already combine const stores up-to MOVQstoreconst. Combine 2 64-bit stores of const zero into 1 sse store of 128-bit zero. Shaves significant (>1%) amount of code from go tool: /localdisk/itocar/golang/bin/go 10334877 go_old 10388125 [53248 bytes] global text (code) = 51041 bytes (1.343944%) read-only data = 663 bytes (0.039617%) Total difference 51704 bytes (0.873981%) Change-Id: I7bc40968023c3a69f379b10fbb433cdb11364f1b Reviewed-on: https://go-review.googlesource.com/56250 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Giovanni Bajo <rasky@develer.com> Reviewed-by:
-
isharipo authored
Instructions are implemented in the following revisions: PCMPESTRI - https://golang.org/cl/22337 PHMINPOSUW - https://golang.org/cl/18853 It is unknown when x86test will be updated/re-run, but tests are useful to check which x86 instructions are not yet supported. As an example of tool that uses this information, there is Damien Lespiau x86db. Part of the mission to add missing amd64 SSE4 instructions to Go asm. Change-Id: I512ff26040f47a0976b3e37000fb1f37eac5b762 Reviewed-on: https://go-review.googlesource.com/55830 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ilya Tocar <ilya.tocar@intel.com>
-
Bryan C. Mills authored
This makes it much easier to run individual failing subtests. Use $(go env CC) instead of always defaulting to clang; this makes it easier to test with other compilers. Run C binaries to detect incompatible compiler/kernel pairings instead of sniffing versions. updates #21196 Change-Id: I0debb3cc4a4244df44b825157ffdc97b5c09338d Reviewed-on: https://go-review.googlesource.com/52910 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
crvv authored
The existing implementation is translated from C, which uses a polynomial coefficient very close to 1/6. If the function uses 1/6 as this coeffient, the result of Exp(1) will be more accurate. And this change doesn't introduce more error to Exp function. Fixes #20319 Change-Id: I94c236a18cf95570ebb69f7fb99884b0d7cf5f6e Reviewed-on: https://go-review.googlesource.com/49294Reviewed-by:
-
Daniel Martí authored
Prioritized the chunks of code with 8 or more levels of indentation. Basically early breaks/returns and joining nested ifs. Change-Id: I6817df1303226acf2eb904a29f2db720e4f7427a Reviewed-on: https://go-review.googlesource.com/55630 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Hiroshi Ioka authored
Current code detect runtime/cgo iff the package or sub packages imports runtime/cgo directly. However, when we are using linkshared, imported shared libraries might have already included runtime/cgo. This CL handles later case by looking an actual runtime/cgo symbol. Change-Id: I35e7dfdb5e1a939eafc95a0259ee1af9782bc864 Reviewed-on: https://go-review.googlesource.com/56310Reviewed-by:
-
Hiroshi Ioka authored
While LoadCmdDylib represents LC_LOAD_DYLIB, LoadCmdDylinker represents LC_ID_DYLINKER. This is confusing because there is another command called LC_LOAD_DYLINKER. LC_ID_DYLINKER is not included in normal binary, it is only used for /usr/lib/dyld as far as I know. So, perhaps this is a mistake. Change-Id: I6ea61664a26998962742914af5688e094a233541 Reviewed-on: https://go-review.googlesource.com/56330Reviewed-by:
-
Hiroshi Ioka authored
add tests for LC_LOAD_DYLIB. Change-Id: Ic4b7a0f6296709175e9a75240aecd1d5291ade4b Reviewed-on: https://go-review.googlesource.com/56311Reviewed-by:
-
Ian Lance Taylor authored
Test is not run in short mode, except on builders. Change-Id: I4456830770188951e05ac13669e834a25bf569ae Reviewed-on: https://go-review.googlesource.com/55973 Run-TryBot: Ian Lance Taylor <iant@golang.org> Run-TryBot: Joe Tsai <joetsai@google.com> Reviewed-by:
Joe Tsai <joetsai@google.com> Reviewed-by:
Marvin Stenger <marvin.stenger94@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Hiroshi Ioka authored
Currently, we have a workaround for solaris that enforce aboslute addressing for external symbols. However, We don't want to use the workaround for darwin. This CL also refactors code a little bit, because the original function name is not appropriate now. Updates #17490 Change-Id: Id21f9cdf33dca6a40647226be49010c2c324ee24 Reviewed-on: https://go-review.googlesource.com/54871Reviewed-by:
-
- 16 Aug, 2017 15 commits
-
-
Hiroshi Ioka authored
* group load command structs. * use hex literal for LoadCommand. Decimal number is not a proper representation for some commands. (e.g. LC_RPATH = 0x8000001c) * move Symbol struct from macho.go to file.go. Symbol is a high level representation, not in Mach-O. Change-Id: I3c69923cb464fb1211f2e766c02e1b537e0b5de2 Reviewed-on: https://go-review.googlesource.com/56130Reviewed-by:
-
Kyle Shannon authored
Fixes #10010. Change-Id: Ib13ac28eafed72c456d8b5b6549015cdf5fdda94 Reviewed-on: https://go-review.googlesource.com/56190Reviewed-by:
-
Michael Steinert authored
When calling a Go function that returns multiple values from C, cgo generates a structure to hold the values. According to the documentation this structure is called `struct <function-name>_return`. When compiling for gccgo the generated structure name is `struct <function-name>_result`. This change updates the output for gccgo to match the documentation and output for gc. Fixes #20910 Change-Id: Iaea8030a695a7aaf9d9f317447fc05615d8e4adc Reviewed-on: https://go-review.googlesource.com/49350Reviewed-by:
-
Ian Lance Taylor authored
Fixes #21456 Change-Id: Iba7bc608686536b2d4fe3d23409fa84b59cea640 Reviewed-on: https://go-review.googlesource.com/55971Reviewed-by:
-
Bryan C. Mills authored
fixes #21481 Change-Id: I26717876a1c0ee25a86c81159c6b3c59563dfec6 Reviewed-on: https://go-review.googlesource.com/56230Reviewed-by:
-
Agniva De Sarker authored
According to the discussion on golang.org/cl/55210, adding benchmarks for reading from and writing to tar archives. Splitting the benchmarks into 3 sections of USTAR, GNU, PAX each. Results ran with -cpu=1 -count=10 on an amd64 machine (i5-5200U CPU @ 2.20GHz) name time/op /Writer/USTAR 5.31µs ± 0% /Writer/GNU 5.01µs ± 1% /Writer/PAX 11.0µs ± 2% /Reader/USTAR 3.22µs ± 1% /Reader/GNU 3.04µs ± 1% /Reader/PAX 7.48µs ± 1% name alloc/op /Writer/USTAR 1.20kB ± 0% /Writer/GNU 1.15kB ± 0% /Writer/PAX 2.61kB ± 0% /Reader/USTAR 1.38kB ± 0% /Reader/GNU 1.35kB ± 0% /Reader/PAX 4.91kB ± 0% name allocs/op /Writer/USTAR 53.0 ± 0% /Writer/GNU 47.0 ± 0% /Writer/PAX 107 ± 0% /Reader/USTAR 32.0 ± 0% /Reader/GNU 30.0 ± 0% /Reader/PAX 67.0 ± 0% Change-Id: I58b1b85b52e58cbd566736aae4d722a3ddf2395b Reviewed-on: https://go-review.googlesource.com/55254Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David du Colombier authored
TestSizes has been added in CL 50170. This test is failing on Plan 9 because executables don't have a DWARF symbol table. Fixes #21480. Change-Id: I51079abdc18ad944617bdbcfe2dad970a0cea0f2 Reviewed-on: https://go-review.googlesource.com/56210 Run-TryBot: David du Colombier <0intro@gmail.com> Reviewed-by:
-
Bryan C. Mills authored
We use a call to strncpy to work around a TSAN bug (wherein TSAN only delivers asynchronous signals when the thread receiving the signal calls a libc function). Unfortunately, GCC 7 inlines the call, avoiding the TSAN libc trap entirely. Per Ian's suggestion, use global variables as strncpy arguments: that way, the compiler can't make any assumptions about the concrete values and can't inline the call away. fixes #21196 Change-Id: Ie95f1feaf9af1a8056f924f49c29cfc8515385d7 Reviewed-on: https://go-review.googlesource.com/55872Reviewed-by:
-
Blain Smith authored
Change-Id: I901f995f8aedee47c48252745816e53192d4b7e4 Reviewed-on: https://go-review.googlesource.com/49090Reviewed-by:
Sam Whited <sam@samwhited.com> Reviewed-by:
-
Cherry Zhang authored
This should fix NaCl build failure for CL 49530. Change-Id: Id9a54f0c81b1b5db5b5efb12a2ad6509c4ab42b3 Reviewed-on: https://go-review.googlesource.com/55770Reviewed-by:
-
Wei Xiao authored
Vendor from golang.org/x/arch (commit f185940). Implements #19157 Updates #12840 Updates #20762 Updates #20897 Updates #20096 Updates #20766 Updates #20752 Updates #20096 Updates #19142 Change-Id: Idefb8ba2c355dc07f3b9e8dcf5f00173256a0f0f Reviewed-on: https://go-review.googlesource.com/49530Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Alberto Donizetti authored
There are a few cases where this can be useful. Apart from the obvious (and silly) 100*n + 200*n where we generate one IMUL instead of two, consider: 15*n + 31*n Currently, the compiler strength-reduces both imuls, generating: 0x0000 00000 MOVQ "".n+8(SP), AX 0x0005 00005 MOVQ AX, CX 0x0008 00008 SHLQ $4, AX 0x000c 00012 SUBQ CX, AX 0x000f 00015 MOVQ CX, DX 0x0012 00018 SHLQ $5, CX 0x0016 00022 SUBQ DX, CX 0x0019 00025 ADDQ CX, AX 0x001c 00028 MOVQ AX, "".~r1+16(SP) 0x0021 00033 RET But combining the imuls is both faster and shorter: 0x0000 00000 MOVQ "".n+8(SP), AX 0x0005 00005 IMULQ $46, AX 0x0009 00009 MOVQ AX, "".~r1+16(SP) 0x000e 00014 RET even without strength-reduction. Moreover, consider: 5*n + 7*(n+1) + 11*(n+2) We already have a rule that rewrites 7(n+1) into 7n+7, so the generated code (without imuls merging) looks like this: 0x0000 00000 MOVQ "".n+8(SP), AX 0x0005 00005 LEAQ (AX)(AX*4), CX 0x0009 00009 MOVQ AX, DX 0x000c 00012 NEGQ AX 0x000f 00015 LEAQ (AX)(DX*8), AX 0x0013 00019 ADDQ CX, AX 0x0016 00022 LEAQ (DX)(CX*2), CX 0x001a 00026 LEAQ 29(AX)(CX*1), AX 0x001f 00031 MOVQ AX, "".~r1+16(SP) But with imuls merging, the 5n, 7n and 11n factors get merged, and the generated code looks like this: 0x0000 00000 MOVQ "".n+8(SP), AX 0x0005 00005 IMULQ $23, AX 0x0009 00009 ADDQ $29, AX 0x000d 00013 MOVQ AX, "".~r1+16(SP) 0x0012 00018 RET Which is both faster and shorter; that's also the exact same code that clang and the intel c compiler generate for the above expression. Change-Id: Ib4d5503f05d2f2efe31a1be14e2fe6cac33730a9 Reviewed-on: https://go-review.googlesource.com/55143Reviewed-by: -
Keith Randall authored
The DWARF entries for type-specific sudog entries used the channel value type instead of a pointer-to-value type for the elem field. Fixes #21094 R=go1.10 Change-Id: I3f63a5664f42b571f729931309f2c9f6f38ab031 Reviewed-on: https://go-review.googlesource.com/50170Reviewed-by:
-
Ilya Tocar authored
Use 16-byte stores instead of 8-byte stores to zero small blocks. Also switch to duffzero for 65+ bytes only, because for each duffzero call we also save/restore BP, so call requires 4 instructions and replacing it with 4 sse stores doesn't cause code-bloat. Also switch duffzero to use leaq, instead of addq to avoid clobbering flags. ClearFat8-6 0.54ns ± 0% 0.54ns ± 0% ~ (all equal) ClearFat12-6 1.07ns ± 0% 1.07ns ± 0% ~ (all equal) ClearFat16-6 1.07ns ± 0% 0.69ns ± 0% -35.51% (p=0.001 n=8+9) ClearFat24-6 1.61ns ± 1% 1.07ns ± 0% -33.33% (p=0.000 n=10+10) ClearFat32-6 2.14ns ± 0% 1.07ns ± 0% -50.00% (p=0.001 n=8+9) ClearFat40-6 2.67ns ± 1% 1.61ns ± 0% -39.72% (p=0.000 n=10+8) ClearFat48-6 3.75ns ± 0% 2.68ns ± 0% -28.59% (p=0.000 n=9+9) ClearFat56-6 4.29ns ± 0% 3.22ns ± 0% -25.10% (p=0.000 n=9+9) ClearFat64-6 4.30ns ± 0% 3.22ns ± 0% -25.15% (p=0.000 n=8+8) ClearFat128-6 7.50ns ± 1% 7.51ns ± 0% ~ (p=0.767 n=10+9) ClearFat256-6 13.9ns ± 1% 13.9ns ± 1% ~ (p=0.257 n=10+10) ClearFat512-6 26.8ns ± 0% 26.8ns ± 0% ~ (p=0.467 n=8+8) ClearFat1024-6 52.5ns ± 0% 52.5ns ± 0% ~ (p=1.000 n=8+8) Also shaves ~20kb from go tool: go_old 10384994 go_new 10364514 [-20480 bytes] section differences global text (code) = -20585 bytes (-0.532047%) read-only data = -302 bytes (-0.018101%) Total difference -20887 bytes (-0.348731%) Change-Id: I15854e87544545c1af24775df895e38e16e12694 Reviewed-on: https://go-review.googlesource.com/54410 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
griesemer authored
If the source importer only encounters "soft" type checking errors it can safely return the type-checked package because it will be completely set up. This makes the source importer slightly more robust in the presence of errors. Fixes #20855. Change-Id: I5af9ccdb30eee6bca7a0fab872f6057bde521bf3 Reviewed-on: https://go-review.googlesource.com/55730Reviewed-by:
Alan Donovan <adonovan@google.com>
-
