- 21 Feb, 2018 12 commits
-
-
Alberto Donizetti authored
For now, limited to the most repetitive rules that are also short and simple, so that we can have a substantial conciseness win without compromising rules readability. Ran rulegen, no change in the actual compiler code (as expected). Change-Id: Ia74acc389cd8310eb7fe8f927171fa3d292d2a86 Reviewed-on: https://go-review.googlesource.com/95797Reviewed-by:
Giovanni Bajo <rasky@develer.com>
-
Alberto Donizetti authored
For now, limited to the most repetitive rules that are also short and simple, so that we can have a substantial conciseness win without compromising rules readability. Ran rulegen, no change in the actual compiler code (as expected). Change-Id: Ib0bfbbc181fcec095fb78ac752addd1eee0c3575 Reviewed-on: https://go-review.googlesource.com/95796Reviewed-by:
-
Giovanni Bajo authored
No changes in the generated file, as expected. Change-Id: I30e0404612cd150f1455378b8db1c18b1e12d34e Reviewed-on: https://go-review.googlesource.com/95616Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Daniel Martí authored
We did warn on them in some cases, but not others. In particular, if one used a slice composite literal with struct pointer elements, and omitted the type of an element's composite literal, it would not get any warning even if it should get one. The issue is that typ.Underlying() can be of type *types.Pointer. Skip those levels of indirection before checking for a *types.Struct underlying type. isLocalType also needed a bit of tweaking to ignore dereferences. Perhaps that can be rewritten now that we have type info, but let's leave it for another time. Fixes #23539. Change-Id: I727a497284df1325b70d47a756519f5db1add25d Reviewed-on: https://go-review.googlesource.com/89715 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Giovanni Bajo authored
Sometimes, multiple CLs being merged that create rules on the same opcodes can cause the generated file to differ compared to a new regeneration. This is caused by the fact that rulegen splits generated functions in chunks of 10 rules per function (to avoid creating functions that are too big). If two CLs add rules to the same function, they might cause a generated function to have more than 10 rules, even though each CL individually didn't pass this limit. Change-Id: Ib641396b7e9028f80ec8718746969d390a9fbba9 Reviewed-on: https://go-review.googlesource.com/95795 Run-TryBot: Giovanni Bajo <rasky@develer.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
-
Mansour Rahimi authored
Calling UDPConn readers (Read, ReadFrom, ReadMsgUDP) to read part of datagram returns error (in Windows), mentioning there is more data available, and 0 as size of read data, even though part of data is already read. This fix makes UDPConn readers to return truncated payload size, even there is error due more data available to read. Fixes #14074 Updates #18056 Change-Id: Id7eec7f544dd759b2d970fa2561eef2937ec4662 Reviewed-on: https://go-review.googlesource.com/92475 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Mikio Hara <mikioh.mikioh@gmail.com>
-
Alberto Donizetti authored
For now, limited to the most repetitive rules that are also short and simple, so that we can have a substantial conciseness win without compromising rules readability. Ran rulegen, no change in the actual compiler code (as expected). Change-Id: Ib1d2b9fbc787379105ec9baf10d2c1e2ff3c4c5c Reviewed-on: https://go-review.googlesource.com/95615Reviewed-by:
-
Ahmed W authored
GitHub-Last-Rev: ff68319f4c46271ddb927d176756962a3a2b4332 GitHub-Pull-Request: golang/go#23874 Change-Id: I7242c5cc35f04e23d807f5e91180c4ef510e7d1a Reviewed-on: https://go-review.googlesource.com/94840Reviewed-by:
-
Austin Clements authored
We don't want to account the memory for mheap_.arenas because most of it is never touched, so currently we pass the address of a uint64 on the heap. However, at least on mips, it's possible for this uint64 to be unaligned, which causes the atomic add in mSysStatInc to crash. Fix this by instead passing a nil stat pointer. Fixes #23946. Change-Id: I091587df1b3066c330b6bb4d834e4596c407910f Reviewed-on: https://go-review.googlesource.com/95695 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Andrew Bonventre authored
+ Move from Markdown checklist to text. The first PR comment is presented as text when creating it. + Add the note about Signed-Off-By: not being required. Change-Id: I0650891dcf11ed7dd367007148730ba2917784fe Reviewed-on: https://go-review.googlesource.com/95696Reviewed-by:
-
Ilya Tocar authored
Currently zip benchmarks spend 60% in the rleBuffer code, which is used only to test zip archive/zip itself: 17.48s 37.02% 37.02% 18.12s 38.37% archive/zip.(*rleBuffer).ReadAt 9.51s 20.14% 57.16% 10.43s 22.09% archive/zip.(*rleBuffer).Write 9.15s 19.38% 76.54% 10.85s 22.98% compress/flate.(*compressor).deflate This means that benchmarks currently test performance of test helper. Updating ReadAt/Write methods to be more performant makes benchmarks closer to real world. name old time/op new time/op delta CompressedZipGarbage-8 2.34ms ± 0% 2.34ms ± 1% ~ (p=0.684 n=10+10) Zip64Test-8 58.1ms ± 2% 10.7ms ± 1% -81.54% (p=0.000 n=10+10) Zip64TestSizes/4096-8 4.05µs ± 2% 3.65µs ± 5% -9.96% (p=0.000 n=9+10) Zip64TestSizes/1048576-8 238µs ± 0% 43µs ± 0% -82.06% (p=0.000 n=10+10) Zip64TestSizes/67108864-8 15.3ms ± 1% 2.6ms ± 0% -83.12% (p=0.000 n=10+9) name old alloc/op new alloc/op delta CompressedZipGarbage-8 17.9kB ±14% 16.0kB ±24% -10.48% (p=0.026 n=9+10) name old allocs/op new allocs/op delta CompressedZipGarbage-8 44.0 ± 0% 44.0 ± 0% ~ (all equal) Change-Id: Idfd920d0e4bed4aec2f5be84dc7e3919d9f1dd2d Reviewed-on: https://go-review.googlesource.com/83857Reviewed-by: -
Martin Möhrmann authored
reflect.unsafe_New is an often called function according to profiling in a large production environment. Since newobject is not inlined currently there is call overhead that can be avoided by calling mallocgc directly. name old time/op new time/op delta New 32.4ns ± 2% 29.8ns ± 1% -8.03% (p=0.000 n=19+20) Change-Id: I572e4be830ed8e5c0da555dc3a8864c8363112be Reviewed-on: https://go-review.googlesource.com/95015Reviewed-by:
Austin Clements <austin@google.com>
-
- 20 Feb, 2018 27 commits
-
-
Ilya Tocar authored
Similar to https://golang.org/cl/54391, but for sha512 name old time/op new time/op delta Hash8Bytes-8 289ns ± 1% 253ns ± 2% -12.59% (p=0.000 n=10+10) Hash1K-8 1.85µs ± 1% 1.82µs ± 1% -1.77% (p=0.000 n=9+10) Hash8K-8 12.7µs ± 2% 12.5µs ± 1% ~ (p=0.075 n=10+10) name old speed new speed delta Hash8Bytes-8 27.6MB/s ± 1% 31.6MB/s ± 2% +14.43% (p=0.000 n=10+10) Hash1K-8 554MB/s ± 1% 564MB/s ± 1% +1.81% (p=0.000 n=9+10) Hash8K-8 647MB/s ± 2% 653MB/s ± 1% ~ (p=0.075 n=10+10) Change-Id: I437668c96ad55f8dbb62c89c8fc3f433453b5330 Reviewed-on: https://go-review.googlesource.com/82996 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Filippo Valsorda <hi@filippo.io>
-
Ilya Tocar authored
Similar to https://golang.org/cl/54391, but for sha256 name old time/op new time/op delta Hash8Bytes-8 209ns ± 1% 191ns ± 1% -8.65% (p=0.000 n=10+9) Hash1K-8 2.49µs ± 1% 2.47µs ± 2% -0.74% (p=0.045 n=9+10) Hash8K-8 18.4µs ± 1% 18.2µs ± 0% -0.98% (p=0.009 n=10+10) name old speed new speed delta Hash8Bytes-8 38.1MB/s ± 1% 41.8MB/s ± 1% +9.47% (p=0.000 n=10+9) Hash1K-8 412MB/s ± 1% 415MB/s ± 2% ~ (p=0.051 n=9+10) Hash8K-8 445MB/s ± 1% 450MB/s ± 0% +0.98% (p=0.009 n=10+10) Change-Id: I50ca80fc28c279fbb758b7c849f67d8c66391eb6 Reviewed-on: https://go-review.googlesource.com/82995 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Heschi Kreinick authored
For functions with many local variables, keeping track of every LocalSlot for every variable is very expensive. Only track the slots that are actually used by a given variable. Change-Id: Iaafbce030a782b8b8c4a0eb7cf025e59af899ea4 Reviewed-on: https://go-review.googlesource.com/92400Reviewed-by:
David Chase <drchase@google.com>
-
Heschi Kreinick authored
Keeping the start state of each block around costs more than just recomputing them as necessary, especially because many blocks only have one predecessor and don't need any merging at all. Stop storing the start state, and reuse predecessors' end states as much as conveniently possible. Change-Id: I549bad9e1a35af76a974e46fe69f74cd4dce873b Reviewed-on: https://go-review.googlesource.com/92399Reviewed-by:
-
Giovanni Bajo authored
This saves an instruction and a register. The new rules match ~4900 times during all.bash. Change-Id: I2f867c5e70262004e31f545f3bb89e939c45b718 Reviewed-on: https://go-review.googlesource.com/94767Reviewed-by:
Keith Randall <khr@golang.org>
-
Shawn Smith authored
GitHub-Last-Rev: 468df242d07419c228656985702325aa78952d99 GitHub-Pull-Request: golang/go#23935 Change-Id: If751ce3ffa3a4d5e00a3138211383d12cb6b23fc Reviewed-on: https://go-review.googlesource.com/95577 Run-TryBot: Andrew Bonventre <andybons@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Andrew Bonventre <andybons@golang.org>
-
Alberto Donizetti authored
For now, limited to the most repetitive rules that are also short and simple, so that we can have a substantial conciseness win without compromising rules readability. Ran rulegen, no change in the actual compiler code (as expected). Change-Id: Ibf157382fb4544c063fbc80406fb9302430728fe Reviewed-on: https://go-review.googlesource.com/95595Reviewed-by:
-
Alberto Donizetti authored
For now, limited to a few repetitive boolean rules where the win is substantial (4+ variants). Change-Id: I67bce0d356ca7d71a0f15ff98551fe2caff8abf9 Reviewed-on: https://go-review.googlesource.com/95535 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> Reviewed-by:
-
Giovanni Bajo authored
No functional changes. Change-Id: I4a3642d6dedf602a62f5a69cb630d35965ad6b98 Reviewed-on: https://go-review.googlesource.com/94763Reviewed-by:
-
Giovanni Bajo authored
No functional changes. Change-Id: I4ea186b09a0309dfa1a80ff71208af2223997ffe Reviewed-on: https://go-review.googlesource.com/94762Reviewed-by:
-
Hana Kim authored
R=go1.11 Change-Id: Ibb09e309c745eba811a0b53000c063bc10a055e1 Reviewed-on: https://go-review.googlesource.com/90218 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Peter Weinberger <pjw@google.com>
-
Hana Kim authored
R=go1.11 Change-Id: I2d2db148fed96d0fcb228bee414b050fe4e46e2c Reviewed-on: https://go-review.googlesource.com/90217Reviewed-by:
Heschi Kreinick <heschi@google.com>
-
Hana Kim authored
R=go1.11 Change-Id: I5078ab714c8ac2c652e6ec496e01b063235a014a Reviewed-on: https://go-review.googlesource.com/90216 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
This adds the ability to add a #x:y anchor to the trace view URL that causes the viewer to initially select from x ms to y ms. Change-Id: I4a980d8128ecc85dbe41f224e8ae336707a4eaab Reviewed-on: https://go-review.googlesource.com/60794 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Giovanni Bajo authored
In addition to look nicer to the eye, this allows to reformat and indent rules without causing spurious changes to the generated file, making it easier to spot functional changes. After this CL, all CLs that will aggregate rules through the new "|" functionality should cause no changes to the generated files. Change-Id: Icec283585ba8d7b91c79d76513c1d83dca4b30aa Reviewed-on: https://go-review.googlesource.com/95216 Run-TryBot: Giovanni Bajo <rasky@develer.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ilya Tocar authored
Replace some ints with bool and use arrays istead of slices where possible. Change-Id: I510bdaec48f9c437685e72c4a3291cffeb7ef5fc Reviewed-on: https://go-review.googlesource.com/83859 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> Reviewed-by:
-
Ryuma Yoshida authored
Change-Id: Ia5908e94a6bd362099ca3c63f6ffb7e94457131d GitHub-Last-Rev: 545a40571a912f433546d8c94a9d63459313515d GitHub-Pull-Request: golang/go#23942 Reviewed-on: https://go-review.googlesource.com/95435Reviewed-by:
-
Daniel Martí authored
The code was maintaining manual versions of it in multiple places - replace all of them. Change-Id: I04c3063877b05ba914de9f5dddb33ffe09f308fe Reviewed-on: https://go-review.googlesource.com/95356 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Kunpei Sakai authored
This follows up CL95235 Change-Id: I62652654e5bb46d2f8f37af468e1fbcc1835bb8a Reviewed-on: https://go-review.googlesource.com/95295Reviewed-by:
-
Daniel Martí authored
Using stringer. Fixes #22684. Change-Id: I62fbde5dcb337cf269686615616bd39a27491ac1 Reviewed-on: https://go-review.googlesource.com/95355 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ben Shi authored
A pair of MUL/NEG instructions can be combined to a single MNEG on ARM64. This CL implements this optimization. 1. A special test case gets big improvement. (https://github.com/benshi001/ugo1/blob/master/mneg_test.go) name old time/op new time/op delta MNEG-4 315µs ± 0% 260µs ± 0% -17.39% (p=0.000 n=24+25) 2. There is little change in the go1 benchmark, excluding noise. name old time/op new time/op delta BinaryTree17-4 42.2s ± 2% 41.9s ± 2% -0.82% (p=0.001 n=30+26) Fannkuch11-4 32.9s ± 0% 32.9s ± 0% -0.01% (p=0.006 n=20+26) FmtFprintfEmpty-4 541ns ± 3% 534ns ± 0% -1.24% (p=0.003 n=30+26) FmtFprintfString-4 1.09µs ± 0% 1.10µs ± 3% ~ (p=0.142 n=23+30) FmtFprintfInt-4 1.14µs ± 0% 1.14µs ± 0% ~ (p=0.435 n=24+24) FmtFprintfIntInt-4 1.76µs ± 0% 1.76µs ± 0% ~ (p=0.508 n=24+26) FmtFprintfPrefixedInt-4 2.20µs ± 3% 2.17µs ± 0% -1.10% (p=0.017 n=30+24) FmtFprintfFloat-4 3.28µs ± 0% 3.28µs ± 0% ~ (p=0.579 n=24+24) FmtManyArgs-4 7.30µs ± 0% 7.30µs ± 0% ~ (p=0.662 n=26+27) GobDecode-4 94.8ms ± 0% 94.8ms ± 0% +0.07% (p=0.010 n=25+23) GobEncode-4 80.9ms ± 4% 80.6ms ± 4% ~ (p=0.901 n=30+30) Gzip-4 4.45s ± 0% 4.49s ± 0% +0.98% (p=0.000 n=25+24) Gunzip-4 450ms ± 3% 443ms ± 0% ~ (p=0.942 n=30+26) HTTPClientServer-4 548µs ± 1% 551µs ± 1% +0.60% (p=0.000 n=29+30) JSONEncode-4 210ms ± 0% 211ms ± 0% +0.03% (p=0.000 n=23+25) JSONDecode-4 866ms ± 5% 877ms ± 5% ~ (p=0.187 n=30+30) Mandelbrot200-4 51.4ms ± 0% 52.0ms ± 3% +1.15% (p=0.001 n=24+30) GoParse-4 42.9ms ± 5% 41.9ms ± 0% -2.24% (p=0.000 n=30+26) RegexpMatchEasy0_32-4 1.02µs ± 3% 1.01µs ± 0% ~ (p=0.247 n=30+26) RegexpMatchEasy0_1K-4 3.90µs ± 0% 3.90µs ± 0% ~ (p=0.062 n=24+24) RegexpMatchEasy1_32-4 955ns ± 0% 956ns ± 0% +0.16% (p=0.000 n=25+23) RegexpMatchEasy1_1K-4 6.42µs ± 3% 6.37µs ± 0% -0.81% (p=0.012 n=30+24) RegexpMatchMedium_32-4 1.77µs ± 3% 1.79µs ± 0% +1.28% (p=0.003 n=30+24) RegexpMatchMedium_1K-4 561µs ± 0% 569µs ± 3% +1.50% (p=0.000 n=25+30) RegexpMatchHard_32-4 31.0µs ± 4% 30.8µs ± 0% ~ (p=1.000 n=26+26) RegexpMatchHard_1K-4 945µs ± 3% 945µs ± 3% ~ (p=0.513 n=30+30) Revcomp-4 7.76s ± 4% 7.68s ± 0% ~ (p=0.464 n=29+23) Template-4 903ms ± 5% 904ms ± 5% ~ (p=0.248 n=30+30) TimeParse-4 4.80µs ± 0% 4.80µs ± 0% ~ (p=0.081 n=25+26) TimeFormat-4 4.70µs ± 1% 4.70µs ± 1% ~ (p=0.763 n=24+26) [Geo mean] 709µs 708µs -0.09% name old speed new speed delta GobDecode-4 8.10MB/s ± 0% 8.09MB/s ± 0% ~ (p=0.160 n=25+23) GobEncode-4 9.49MB/s ± 4% 9.53MB/s ± 4% ~ (p=0.360 n=30+30) Gzip-4 4.36MB/s ± 0% 4.32MB/s ± 0% -0.92% (p=0.000 n=25+24) Gunzip-4 43.2MB/s ± 3% 43.8MB/s ± 0% ~ (p=0.980 n=30+26) JSONEncode-4 9.22MB/s ± 0% 9.22MB/s ± 0% -0.04% (p=0.005 n=23+25) JSONDecode-4 2.24MB/s ± 5% 2.21MB/s ± 4% ~ (p=0.252 n=30+30) GoParse-4 1.35MB/s ± 5% 1.38MB/s ± 0% +2.00% (p=0.003 n=30+26) RegexpMatchEasy0_32-4 31.5MB/s ± 3% 31.8MB/s ± 0% ~ (p=0.110 n=30+26) RegexpMatchEasy0_1K-4 263MB/s ± 0% 263MB/s ± 0% ~ (p=0.111 n=24+24) RegexpMatchEasy1_32-4 33.5MB/s ± 0% 33.4MB/s ± 0% -0.16% (p=0.003 n=25+23) RegexpMatchEasy1_1K-4 160MB/s ± 3% 161MB/s ± 0% +0.78% (p=0.012 n=30+24) RegexpMatchMedium_32-4 565kB/s ± 3% 560kB/s ± 0% -0.83% (p=0.001 n=30+24) RegexpMatchMedium_1K-4 1.83MB/s ± 0% 1.80MB/s ± 3% -1.56% (p=0.000 n=25+30) RegexpMatchHard_32-4 1.03MB/s ± 3% 1.04MB/s ± 0% +1.46% (p=0.000 n=30+26) RegexpMatchHard_1K-4 1.08MB/s ± 3% 1.09MB/s ± 3% ~ (p=0.444 n=30+30) Revcomp-4 32.8MB/s ± 4% 33.1MB/s ± 0% ~ (p=0.858 n=29+23) Template-4 2.15MB/s ± 5% 2.15MB/s ± 5% ~ (p=0.646 n=30+30) [Geo mean] 7.79MB/s 7.81MB/s +0.21% 3. There is no regression in the compilecmp benchmark. name old time/op new time/op delta Template 2.35s ± 4% 2.33s ± 3% ~ (p=0.796 n=10+10) Unicode 1.35s ± 6% 1.35s ± 5% ~ (p=1.000 n=9+10) GoTypes 8.10s ± 3% 8.14s ± 3% ~ (p=0.604 n=9+10) Compiler 40.5s ± 2% 40.2s ± 2% ~ (p=0.065 n=10+9) SSA 115s ± 2% 115s ± 2% ~ (p=0.447 n=9+10) Flate 1.45s ± 3% 1.45s ± 4% ~ (p=0.739 n=10+10) GoParser 1.85s ± 3% 1.86s ± 2% ~ (p=0.853 n=10+10) Reflect 5.11s ± 2% 5.10s ± 2% ~ (p=0.971 n=10+10) Tar 2.23s ± 5% 2.23s ± 3% ~ (p=0.796 n=10+10) XML 2.67s ± 2% 2.69s ± 2% ~ (p=0.549 n=9+10) [Geo mean] 5.00s 5.00s +0.02% name old user-time/op new user-time/op delta Template 2.88s ± 2% 2.86s ± 2% ~ (p=0.529 n=10+10) Unicode 1.70s ± 7% 1.69s ± 5% ~ (p=0.853 n=10+10) GoTypes 9.72s ± 1% 9.73s ± 1% ~ (p=0.684 n=10+10) Compiler 49.0s ± 1% 48.9s ± 1% ~ (p=0.631 n=10+10) SSA 144s ± 1% 144s ± 2% ~ (p=0.684 n=10+10) Flate 1.71s ± 4% 1.72s ± 4% ~ (p=0.853 n=10+10) GoParser 2.23s ± 2% 2.23s ± 2% ~ (p=0.971 n=10+10) Reflect 5.98s ± 2% 5.96s ± 2% ~ (p=0.481 n=10+10) Tar 2.68s ± 3% 2.67s ± 2% ~ (p=0.393 n=10+10) XML 3.21s ± 3% 3.22s ± 1% ~ (p=0.604 n=10+9) [Geo mean] 6.05s 6.05s -0.04% name old text-bytes new text-bytes delta HelloSize 641kB ± 0% 641kB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 9.46kB ± 0% 9.46kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 125kB ± 0% 125kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.24MB ± 0% 1.24MB ± 0% ~ (all equal) Change-Id: I9ed9128f0114e0f1ebb08ca2d042c90fcb2b1dcd Reviewed-on: https://go-review.googlesource.com/95075Reviewed-by:
-
Richard Miller authored
On Plan 9, the underlying create() syscall with DMDIR flag, which is used to implement Mkdir, will fail silently if the path exists and is not a directory. Work around this by checking for existence first and rejecting Mkdir with error EEXIST if the path is found. Fixes #23918 Change-Id: I439115662307923c9f498d3e7b1f32c6d205e1ad Reviewed-on: https://go-review.googlesource.com/94777Reviewed-by:
David du Colombier <0intro@gmail.com>
-
Mikio Hara authored
We live in the era of virtualization and isolation. There is no reason to hesitate to use IPv4 loopback address block for umbrella-type customer accommodating services. Fixes #23903 Change-Id: I990dd98e2651a993dac1b105c0bc771f8631cb93 Reviewed-on: https://go-review.googlesource.com/95336Reviewed-by:
-
philhofer authored
Introduce a new SSA pass to generate CondSelect intstrutions, and add CondSelect lowering rules for arm64. In order to make the CSEL instruction easier to optimize, and to simplify the introduction of CSNEG, CSINC, and CSINV in the future, modify the CSEL instruction to accept a condition code in the aux field. Notably, this change makes the go1 Gzip benchmark more than 10% faster. Benchmarks on a Cavium ThunderX: name old time/op new time/op delta BinaryTree17-96 15.9s ± 6% 16.0s ± 4% ~ (p=0.968 n=10+9) Fannkuch11-96 7.17s ± 0% 7.00s ± 0% -2.43% (p=0.000 n=8+9) FmtFprintfEmpty-96 208ns ± 1% 207ns ± 0% ~ (p=0.152 n=10+8) FmtFprintfString-96 379ns ± 0% 375ns ± 0% -0.95% (p=0.000 n=10+9) FmtFprintfInt-96 385ns ± 0% 383ns ± 0% -0.52% (p=0.000 n=9+10) FmtFprintfIntInt-96 591ns ± 0% 586ns ± 0% -0.85% (p=0.006 n=7+9) FmtFprintfPrefixedInt-96 656ns ± 0% 667ns ± 0% +1.71% (p=0.000 n=10+10) FmtFprintfFloat-96 967ns ± 0% 984ns ± 0% +1.78% (p=0.000 n=10+10) FmtManyArgs-96 2.35µs ± 0% 2.25µs ± 0% -4.63% (p=0.000 n=9+8) GobDecode-96 31.0ms ± 0% 30.8ms ± 0% -0.36% (p=0.006 n=9+9) GobEncode-96 24.4ms ± 0% 24.5ms ± 0% +0.30% (p=0.000 n=9+9) Gzip-96 1.60s ± 0% 1.43s ± 0% -10.58% (p=0.000 n=9+10) Gunzip-96 167ms ± 0% 169ms ± 0% +0.83% (p=0.000 n=8+9) HTTPClientServer-96 311µs ± 1% 308µs ± 0% -0.75% (p=0.000 n=10+10) JSONEncode-96 65.0ms ± 0% 64.8ms ± 0% -0.25% (p=0.000 n=9+8) JSONDecode-96 262ms ± 1% 261ms ± 1% ~ (p=0.579 n=10+10) Mandelbrot200-96 18.0ms ± 0% 18.1ms ± 0% +0.17% (p=0.000 n=8+10) GoParse-96 14.0ms ± 0% 14.1ms ± 1% +0.42% (p=0.003 n=9+10) RegexpMatchEasy0_32-96 644ns ± 2% 645ns ± 2% ~ (p=0.836 n=10+10) RegexpMatchEasy0_1K-96 3.70µs ± 0% 3.49µs ± 0% -5.58% (p=0.000 n=10+10) RegexpMatchEasy1_32-96 662ns ± 2% 657ns ± 2% ~ (p=0.137 n=10+10) RegexpMatchEasy1_1K-96 4.47µs ± 0% 4.31µs ± 0% -3.48% (p=0.000 n=10+10) RegexpMatchMedium_32-96 844ns ± 2% 849ns ± 1% ~ (p=0.208 n=10+10) RegexpMatchMedium_1K-96 179µs ± 0% 182µs ± 0% +1.20% (p=0.000 n=10+10) RegexpMatchHard_32-96 10.0µs ± 0% 10.1µs ± 0% +0.48% (p=0.000 n=10+9) RegexpMatchHard_1K-96 297µs ± 0% 297µs ± 0% -0.14% (p=0.000 n=10+10) Revcomp-96 3.08s ± 0% 3.13s ± 0% +1.56% (p=0.000 n=9+9) Template-96 276ms ± 2% 275ms ± 1% ~ (p=0.393 n=10+10) TimeParse-96 1.37µs ± 0% 1.36µs ± 0% -0.53% (p=0.000 n=10+7) TimeFormat-96 1.40µs ± 0% 1.42µs ± 0% +0.97% (p=0.000 n=10+10) [Geo mean] 264µs 262µs -0.77% Change-Id: Ie54eee4b3092af53e6da3baa6d1755098f57f3a2 Reviewed-on: https://go-review.googlesource.com/55670 Run-TryBot: Philip Hofer <phofer@umich.edu> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
Updates #23912 Change-Id: I50d06506a8ac91ed99a761a9ff3fd0b03d4c8121 Reviewed-on: https://go-review.googlesource.com/94995 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Url authored
Replace references to the obsoleted RFC 2616 with references to RFC 7230 through 7235, to avoid unnecessary confusion. Obvious inconsistencies are marked with todo comments. Updates #21974 Change-Id: I8fb4fcdd1333fc5193b93a2f09598f18c45e7a00 Reviewed-on: https://go-review.googlesource.com/94095Reviewed-by:
-
Keith Randall authored
When we go from a branch block to a plain block, reset the branch prediction bit. Downstream passes asssume that if the branch prediction is set, then the block has 2 successors. Fixes #23504 Change-Id: I2898ec002228b2e34fe80ce420c6939201c0a5aa Reviewed-on: https://go-review.googlesource.com/88955Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
- 19 Feb, 2018 1 commit
-
-
Alberto Donizetti authored
It appears that old code (from 2009) in xml.(*Decoder).rawToken replicates append's slice-growing functionality by allocating a new, bigger backing array and then calling copy. Simplifying the code by replacing it with a single append call does not seem to hurt performance: name old time/op new time/op delta Marshal-4 11.2µs ± 1% 11.3µs ±10% ~ (p=0.069 n=19+17) Unmarshal-4 28.6µs ± 1% 28.4µs ± 1% -0.60% (p=0.000 n=20+18) name old alloc/op new alloc/op delta Marshal-4 5.78kB ± 0% 5.78kB ± 0% ~ (all equal) Unmarshal-4 8.61kB ± 0% 8.27kB ± 0% -3.90% (p=0.000 n=20+20) name old allocs/op new allocs/op delta Marshal-4 23.0 ± 0% 23.0 ± 0% ~ (all equal) Unmarshal-4 189 ± 0% 190 ± 0% +0.53% (p=0.000 n=20+20) Change-Id: Ie580d1216a44760e611e63dee2c339af5465aea5 Reviewed-on: https://go-review.googlesource.com/86655Reviewed-by:
-
