- 23 Feb, 2018 5 commits
-
-
Alberto Donizetti authored
Add "sqrt-intrisified" code generation tests for mips64 and 386, where we weren't intrisifying math.Sqrt (see CL 96615 and CL 95916), and for mips and amd64, which lacked sqrt intrinsics tests. Change-Id: I0cfc08aec6eefd47f3cd7a5995a89393e8b7ed9e Reviewed-on: https://go-review.googlesource.com/96716 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
mingrammer authored
There was still the word 'Hashmap' in gc_test.go, so I renamed it to just 'Map' Previous renaming commit: https://golang.org/cl/90336 Change-Id: I5b0e5c2229d1c30937c7216247f4533effb81ce7 Reviewed-on: https://go-review.googlesource.com/96675Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alberto Donizetti authored
It seems like all the pieces were already there, it only needed the final plumbing. Before: 0x001b 00027 (test.go:9) MOVSD X0, (SP) 0x0020 00032 (test.go:9) CALL math.Sqrt(SB) 0x0025 00037 (test.go:9) MOVSD 8(SP), X0 After: 0x0018 00024 (test.go:9) SQRTSD X0, X0 name old time/op new time/op delta Sqrt-4 4.60ns ± 2% 0.45ns ± 1% -90.33% (p=0.000 n=10+10) Change-Id: I0f623958e19e726840140bf9b495d3f3a9184b9d Reviewed-on: https://go-review.googlesource.com/96615 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Alberto Donizetti authored
This change or-ifies the last low-hanging rules in generic. Again, this is limited at short and repetitive rules, where the use or ors does not impact readability. Ran rulegen, no change in the actual compiler code. Change-Id: I972b523bc08532f173a3645b47d6936b6e1218c8 Reviewed-on: https://go-review.googlesource.com/96335Reviewed-by: Giovanni Bajo <rasky@develer.com>
-
Jerrin Shaji George authored
Change-Id: I07a1eb02ffc621c5696b49491181300bf411f822 Reviewed-on: https://go-review.googlesource.com/96475Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 22 Feb, 2018 10 commits
-
-
Robert Griesemer authored
Setting -panic will cause gotype to panic with the first reported error, producing a stack trace for debugging. For #23914. Change-Id: I40c41cf10aa13d1dd9a099f727ef4201802de13a Reviewed-on: https://go-review.googlesource.com/96375Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Tobias Klauser authored
The syscall package is frozen and we don't want to encourage anyone to implement these syscalls. Change-Id: I6b6e33e32a4b097da6012226aa15300735e50e9f Reviewed-on: https://go-review.googlesource.com/96315Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Robert Griesemer authored
The variables on the lhs of a short variable declaration are only in scope after the variable declaration. Specifically, function literals on the rhs of a short variable declaration must not see newly declared variables on the lhs. This used to work and this bug was likely introduced with https://go-review.googlesource.com/c/go/+/83397 for go1.11. Luckily this is just an oversight and the fix is trivial: Simply use the mechanism for delayed type-checkin of function literals introduced in the before-mentioned change here as well. Fixes #24026. Change-Id: I74ce3a0d05c5a2a42ce4b27601645964f906e82d Reviewed-on: https://go-review.googlesource.com/96177Reviewed-by: Alan Donovan <adonovan@google.com>
-
Ben Shi authored
Two ARM64 rules are added to avoid FP accuracy issue, which causes build failure. https://build.golang.org/log/1360f5c9ef3f37968216350283c1013e9681725d fixes #24033 Change-Id: I9b74b584ab5cc53fa49476de275dc549adf97610 Reviewed-on: https://go-review.googlesource.com/96355Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alexey Palazhchenko authored
Fixes #23632 Change-Id: I7197e13df6cf28400a6dd86c110f41129550abb6 Reviewed-on: https://go-review.googlesource.com/92235Reviewed-by: Daniel Theophanes <kardianos@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 changes in the rewrite files. Change-Id: I8447784895a218c5c1b4dfa1cdb355bd73dabfd1 Reviewed-on: https://go-review.googlesource.com/95955Reviewed-by: Giovanni Bajo <rasky@develer.com>
-
Martin Möhrmann authored
If the type of Type is known to be *rtype than the common function is a no-op and does not need to be called. name old time/op new time/op delta New 31.0ns ± 5% 30.2ns ± 4% -2.74% (p=0.008 n=20+20) Change-Id: I5d00346dbc782e34c530166d1ee0499b24068b51 Reviewed-on: https://go-review.googlesource.com/96115Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ben Shi authored
FMADD/FMSUB/FNMADD/FNMSUB are efficient FP instructions, which can be used by the comiler to improve FP performance. This CL implements this optimization. 1. The compilecmp benchmark shows little change. name old time/op new time/op delta Template 2.35s ± 4% 2.38s ± 4% ~ (p=0.161 n=15+15) Unicode 1.36s ± 5% 1.36s ± 4% ~ (p=0.685 n=14+13) GoTypes 8.11s ± 3% 8.13s ± 2% ~ (p=0.624 n=15+15) Compiler 40.5s ± 2% 40.7s ± 2% ~ (p=0.137 n=15+15) SSA 115s ± 3% 116s ± 1% ~ (p=0.270 n=15+14) Flate 1.46s ± 4% 1.45s ± 5% ~ (p=0.870 n=15+15) GoParser 1.85s ± 2% 1.87s ± 3% ~ (p=0.477 n=14+15) Reflect 5.11s ± 4% 5.10s ± 2% ~ (p=0.624 n=15+15) Tar 2.23s ± 3% 2.23s ± 5% ~ (p=0.624 n=15+15) XML 2.72s ± 5% 2.74s ± 3% ~ (p=0.290 n=15+14) [Geo mean] 5.02s 5.03s +0.29% name old user-time/op new user-time/op delta Template 2.90s ± 2% 2.90s ± 3% ~ (p=0.780 n=14+15) Unicode 1.71s ± 5% 1.70s ± 3% ~ (p=0.458 n=14+13) GoTypes 9.77s ± 2% 9.76s ± 2% ~ (p=0.838 n=15+15) Compiler 49.1s ± 2% 49.1s ± 2% ~ (p=0.902 n=15+15) SSA 144s ± 1% 144s ± 2% ~ (p=0.567 n=15+15) Flate 1.75s ± 5% 1.74s ± 3% ~ (p=0.461 n=15+15) GoParser 2.22s ± 2% 2.21s ± 3% ~ (p=0.233 n=15+15) Reflect 5.99s ± 2% 5.95s ± 1% ~ (p=0.093 n=14+15) Tar 2.68s ± 2% 2.67s ± 3% ~ (p=0.310 n=14+15) XML 3.22s ± 2% 3.24s ± 3% ~ (p=0.512 n=15+15) [Geo mean] 6.08s 6.07s -0.19% 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) 2. The go1 benchmark shows little improvement in total (excluding noise), but some improvement in test case Mandelbrot200 and FmtFprintfFloat. name old time/op new time/op delta BinaryTree17-4 42.1s ± 2% 42.0s ± 2% ~ (p=0.453 n=30+28) Fannkuch11-4 33.5s ± 3% 33.3s ± 3% -0.38% (p=0.045 n=30+30) FmtFprintfEmpty-4 534ns ± 0% 534ns ± 0% ~ (all equal) FmtFprintfString-4 1.09µs ± 0% 1.09µs ± 0% -0.27% (p=0.000 n=23+17) FmtFprintfInt-4 1.16µs ± 3% 1.16µs ± 3% ~ (p=0.714 n=30+30) FmtFprintfIntInt-4 1.76µs ± 1% 1.77µs ± 0% +0.15% (p=0.002 n=23+23) FmtFprintfPrefixedInt-4 2.21µs ± 3% 2.20µs ± 3% ~ (p=0.390 n=30+30) FmtFprintfFloat-4 3.28µs ± 0% 3.11µs ± 0% -5.01% (p=0.000 n=25+26) FmtManyArgs-4 7.18µs ± 0% 7.19µs ± 0% +0.13% (p=0.000 n=24+25) GobDecode-4 94.9ms ± 0% 95.6ms ± 5% +0.83% (p=0.002 n=23+29) GobEncode-4 80.7ms ± 4% 79.8ms ± 0% -1.11% (p=0.003 n=30+24) Gzip-4 4.58s ± 4% 4.59s ± 3% +0.26% (p=0.002 n=30+26) Gunzip-4 449ms ± 4% 443ms ± 0% ~ (p=0.096 n=30+26) HTTPClientServer-4 553µs ± 1% 548µs ± 1% -0.96% (p=0.000 n=30+30) JSONEncode-4 215ms ± 4% 214ms ± 4% -0.29% (p=0.000 n=30+30) JSONDecode-4 868ms ± 4% 875ms ± 5% +0.79% (p=0.008 n=30+30) Mandelbrot200-4 51.4ms ± 0% 46.7ms ± 3% -9.09% (p=0.000 n=25+26) GoParse-4 42.1ms ± 0% 41.8ms ± 0% -0.61% (p=0.000 n=25+24) RegexpMatchEasy0_32-4 1.02µs ± 4% 1.02µs ± 4% -0.17% (p=0.000 n=30+30) RegexpMatchEasy0_1K-4 3.90µs ± 0% 3.95µs ± 4% ~ (p=0.516 n=23+30) RegexpMatchEasy1_32-4 970ns ± 3% 973ns ± 3% ~ (p=0.951 n=30+30) RegexpMatchEasy1_1K-4 6.43µs ± 3% 6.33µs ± 0% -1.62% (p=0.000 n=30+25) RegexpMatchMedium_32-4 1.75µs ± 0% 1.75µs ± 0% ~ (p=0.422 n=25+24) RegexpMatchMedium_1K-4 568µs ± 3% 562µs ± 0% ~ (p=0.079 n=30+24) RegexpMatchHard_32-4 30.8µs ± 0% 31.2µs ± 4% +1.46% (p=0.018 n=23+30) RegexpMatchHard_1K-4 932µs ± 0% 946µs ± 3% +1.49% (p=0.000 n=24+30) Revcomp-4 7.69s ± 3% 7.69s ± 2% +0.04% (p=0.032 n=24+25) Template-4 893ms ± 5% 880ms ± 6% -1.53% (p=0.000 n=30+30) TimeParse-4 4.90µs ± 3% 4.84µs ± 0% ~ (p=0.080 n=30+25) TimeFormat-4 4.70µs ± 1% 4.76µs ± 0% +1.21% (p=0.000 n=23+26) [Geo mean] 710µs 706µs -0.63% name old speed new speed delta GobDecode-4 8.09MB/s ± 0% 8.03MB/s ± 5% -0.77% (p=0.002 n=23+29) GobEncode-4 9.52MB/s ± 4% 9.62MB/s ± 0% +1.07% (p=0.003 n=30+24) Gzip-4 4.24MB/s ± 4% 4.23MB/s ± 3% -0.35% (p=0.002 n=30+26) Gunzip-4 43.2MB/s ± 4% 43.8MB/s ± 0% ~ (p=0.123 n=30+26) JSONEncode-4 9.03MB/s ± 4% 9.06MB/s ± 4% +0.28% (p=0.000 n=30+30) JSONDecode-4 2.24MB/s ± 4% 2.22MB/s ± 5% -0.79% (p=0.008 n=30+30) GoParse-4 1.38MB/s ± 1% 1.38MB/s ± 0% ~ (p=0.401 n=25+17) RegexpMatchEasy0_32-4 31.4MB/s ± 4% 31.5MB/s ± 3% +0.16% (p=0.000 n=30+30) RegexpMatchEasy0_1K-4 262MB/s ± 0% 259MB/s ± 4% ~ (p=0.693 n=23+30) RegexpMatchEasy1_32-4 33.0MB/s ± 3% 32.9MB/s ± 3% ~ (p=0.139 n=30+30) RegexpMatchEasy1_1K-4 159MB/s ± 3% 162MB/s ± 0% +1.60% (p=0.000 n=30+25) RegexpMatchMedium_32-4 570kB/s ± 0% 570kB/s ± 0% ~ (all equal) RegexpMatchMedium_1K-4 1.80MB/s ± 3% 1.82MB/s ± 0% +1.09% (p=0.007 n=30+24) RegexpMatchHard_32-4 1.04MB/s ± 0% 1.03MB/s ± 3% -1.38% (p=0.003 n=23+30) RegexpMatchHard_1K-4 1.10MB/s ± 0% 1.08MB/s ± 3% -1.52% (p=0.000 n=24+30) Revcomp-4 33.0MB/s ± 3% 33.0MB/s ± 2% ~ (p=0.128 n=24+25) Template-4 2.17MB/s ± 5% 2.21MB/s ± 6% +1.61% (p=0.000 n=30+30) [Geo mean] 7.79MB/s 7.79MB/s +0.05% Change-Id: Ied3dbdb5ba8e386168629cba06fcd4263bbb83e1 Reviewed-on: https://go-review.googlesource.com/94901 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
erifan01 authored
Add arm64 HW instructions FMADDD, FMADDS, FMSUBD, FMSUBS, FNMADDD, FNMADDS, FNMSUBD, FNMSUBS, VFMLA, VFMLS, VMOV (element) for math optimization. Add check on register element index and test cases. Change-Id: Ice07c50b1a02d488ad2cde2a4e8aea93f3e3afff Reviewed-on: https://go-review.googlesource.com/90876Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
David Chase authored
While tinkering with different block orders for the preemptible loop experiment, crashed the register allocator with a "bad" one (these exist). Realized that one knob was controlling two things (register allocation and branch patterns) and decided that life would be simpler if the two orders were independent. Ran some experiments and determined that we have probably, mostly, been optimizing for register allocation effects, not branch effects. Bad block orders for register allocation are somewhat costly. This will also allow separate experimentation with perhaps- better block orders for register allocation. Change-Id: I6ecf2f24cca178b6f8acc0d3c4caaef043c11ed9 Reviewed-on: https://go-review.googlesource.com/47314 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
- 21 Feb, 2018 25 commits
-
-
Hana Kim authored
Enabled when the tool runs with DEBUG_MEMORY_USAGE=1 env var. After reporting the usage, it waits until user enters input (helpful when checking top or other memory monitor) Also adds net/http/pprof to export debug endpoints. From the trace included in #21870 $ DEBUG_MEMORY_USAGE=1 go tool trace trace.out 2018/02/21 16:04:49 Parsing trace... after parsing trace Alloc: 3385747848 Bytes Sys: 3661654648 Bytes HeapReleased: 0 Bytes HeapSys: 3488907264 Bytes HeapInUse: 3426377728 Bytes HeapAlloc: 3385747848 Bytes Enter to continue... 2018/02/21 16:05:09 Serializing trace... after generating trace Alloc: 4908929616 Bytes Sys: 5319063640 Bytes HeapReleased: 0 Bytes HeapSys: 5032411136 Bytes HeapInUse: 4982865920 Bytes HeapAlloc: 4908929616 Bytes Enter to continue... 2018/02/21 16:05:18 Splitting trace... after spliting trace Alloc: 4909026200 Bytes Sys: 5319063640 Bytes HeapReleased: 0 Bytes HeapSys: 5032411136 Bytes HeapInUse: 4983046144 Bytes HeapAlloc: 4909026200 Bytes Enter to continue... 2018/02/21 16:05:39 Opening browser. Trace viewer is listening on http://127.0.0.1:33661 after httpJsonTrace Alloc: 5288336048 Bytes Sys: 7790245896 Bytes HeapReleased: 0 Bytes HeapSys: 7381123072 Bytes HeapInUse: 5324120064 Bytes HeapAlloc: 5288336048 Bytes Enter to continue... Change-Id: I88bb3cb1af3cb62e4643a8cbafd5823672b2e464 Reviewed-on: https://go-review.googlesource.com/92355Reviewed-by: Peter Weinberger <pjw@google.com>
-
Robert Griesemer authored
The existing code was somewhat convoluted and made several assumptions about the encoding of position bases: 1) The position's base for a file contained a position whose base pointed to itself (which is true but an implementation detail of src.Pos). 2) Updating the position base for a line directive required finding the base of the most recent's base position. This change simply stores the file's position base and keeps using it directly for each line directive (instead of getting it from the most recently updated base). Change-Id: I4d80da513bededb636eab0ce53257fda73f0dbc0 Reviewed-on: https://go-review.googlesource.com/95736Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
OneOfOne authored
Fixes #23959 GitHub-Last-Rev: 08ce026f52f9fd65b49d99745dffed46a3951585 GitHub-Pull-Request: golang/go#24012 Change-Id: I7e71c41330346dbc4dad6ba813cabfa8a54e2f66 Reviewed-on: https://go-review.googlesource.com/95975 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Yury Smolsky authored
Fixes #23520 Change-Id: Ia834819f3260691a1a0181034ef4b4b945965688 Reviewed-on: https://go-review.googlesource.com/94761Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Austin Clements authored
Now that we support the full non-contiguous virtual address space of amd64 hardware, some of the comments and constants related to this are out of date. This renames memLimitBits to heapAddrBits because 1<<memLimitBits is no longer the limit of the address space and rewrites the comment to focus first on hardware limits (which span OSes) and then discuss kernel limits. Second, this eliminates the memLimit constant because there's no longer a meaningful "highest possible heap pointer value" on amd64. Updates #23862. Change-Id: I44b32033d2deb6b69248fb8dda14fc0e65c47f11 Reviewed-on: https://go-review.googlesource.com/95498 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Austin Clements authored
On amd64, the virtual address space, when interpreted as signed values, is [-2^47, 2^47). Currently, we only support heap addresses in the "positive" half of this, [0, 2^47). This suffices for linux/amd64 and windows/amd64, but solaris/amd64 can map user addresses in the negative part of this range. Specifically, addresses 0xFFFF8000'00000000 to 0xFFFFFD80'00000000 are part of user space. This leads to "memory allocated by OS not in usable address space" panic, since we don't map heap arena index space for these addresses. Fix this by offsetting addresses when computing arena indexes so that arena entry 0 corresponds to address -2^47 on amd64. We already map enough arena space for 2^48 heap addresses on 64-bit (because arm64's virtual address space is [0, 2^48)), so we don't need to grow any structures to support this. A different approach would be to simply mask out the top 16 bits. However, there are two advantages to the offset approach: 1) invalid heap addresses continue to naturally map to invalid arena indexes so we don't need extra checks and 2) it perturbs the mapping of addresses to arena indexes more, which helps check that we don't accidentally compute incorrect arena indexes somewhere that happen to be right most of the time. Several comments and constant names are now somewhat misleading. We'll fix that in the next CL. This CL is the core change the arena indexing. Fixes #23862. Change-Id: Idb8e299fded04593a286b01a9582da6ddbac2f9a Reviewed-on: https://go-review.googlesource.com/95497 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Accessing the arena index is about to get slightly more complicated. Abstract this away into a set of functions for going back and forth between addresses and arena slice indexes. For #23862. Change-Id: I0b20e74ef47a07b78ed0cf0a6128afe6f6e40f4b Reviewed-on: https://go-review.googlesource.com/95496 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Currently, bulkBarrierPreWrite uses inheap to decide whether the destination is in the heap or whether to check for stack or global data. However, this isn't the best question to ask. Instead, get the span directly and query its state. This lets us directly determine whether this might be a global, or is stack memory, or is heap memory. At this point, inheap is no longer used in the hot path, so drop it from the must-be-inlined list and substitute spanOf. This will help in a circuitous way with #23862, since fixing that is going to push inheap very slightly over the inline-able threshold on a few platforms. Change-Id: I5360fc1181183598502409f12979899e1e4d45f7 Reviewed-on: https://go-review.googlesource.com/95495 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Hana Kim authored
The task-oriented trace view presents the execution trace organized based on goroutines. Often, which P a goroutine was running on is useful, so this CL includes the P ids in the goroutine execution slices. R=go1.11 Change-Id: I96539bf8215e5c1cd8cc997a90204f57347c48c8 Reviewed-on: https://go-review.googlesource.com/90221Reviewed-by: Heschi Kreinick <heschi@google.com>
-
Hana Kim authored
Also append stack traces to task create/end slices. R=go1.11 Change-Id: I2adb342e92b36d30bee2860393618eb4064450cf Reviewed-on: https://go-review.googlesource.com/90220Reviewed-by: Heschi Kreinick <heschi@google.com>
-
Hana Kim authored
The GC time for a task is defined by the sum of GC duration overlapping with the task's duration. Also, grey out non-overlapping slices in the task-oriented trace view. R=go1.11 Change-Id: I42def0eb520f5d9bd07edd265e558706f6fab552 Reviewed-on: https://go-review.googlesource.com/90219Reviewed-by: Heschi Kreinick <heschi@google.com>
-
Heschi Kreinick authored
Reuse even more memory, and keep track of it in a long-lived debugState object rather than piecemeal in the Cache. Change-Id: Ib6936b4e8594dc6dda1f59ece753c00fd1c136ba Reviewed-on: https://go-review.googlesource.com/92404Reviewed-by: David Chase <drchase@google.com>
-
Heschi Kreinick authored
Change the closures to methods on debugState, mostly just for aesthetic reasons. Change-Id: I5242807f7300efafc7efb4eb3bd305ac3ec8e826 Reviewed-on: https://go-review.googlesource.com/92403Reviewed-by: David Chase <drchase@google.com>
-
Heschi Kreinick authored
changedVars was functionally a set, but couldn't be iterated over efficiently. In functions with many variables, the wasted iteration was costly. Use a sparseSet instead. (*gc.Node).String() is very expensive: it calls Sprintf, which does reflection, etc, etc. Instead, just look at .Sym.Name, which is all we care about. Change-Id: Ib61cd7b5c796e1813b8859135e85da5bfe2ac686 Reviewed-on: https://go-review.googlesource.com/92402Reviewed-by: David Chase <drchase@google.com>
-
Heschi Kreinick authored
Replace the OnStack boolean in VarLoc with a flag bit in StackOffset. This doesn't get much memory savings since it's still 64-bit aligned, but does seem to help a bit anyway. Change liveSlot to fit into 16 bytes. Because nested structs still get padding, this required inlining it. Fortunately there's not much logic to copy. Change-Id: Ie19a409daa41aa310275c4517a021eecf8886441 Reviewed-on: https://go-review.googlesource.com/92401Reviewed-by: David Chase <drchase@google.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 changes in the rewrite files. Change-Id: I8d8cc67d02faca4756cc02402b763f1645ee31de Reviewed-on: https://go-review.googlesource.com/95935Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alberto Donizetti authored
Fixes #24006 Change-Id: Ic1438b121fe705f9a6e3ed8340882e9dfd26ecf7 Reviewed-on: https://go-review.googlesource.com/95916Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.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: 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 <rasky@develer.com>
-
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: Brad Fitzpatrick <bradfitz@golang.org>
-
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: Brad Fitzpatrick <bradfitz@golang.org>
-
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: Brad Fitzpatrick <bradfitz@golang.org>
-