When processing a fallthrough, the casebody function in swt.go
checks that the last statement has indeed Op == OXFALL (not-processed
fallthrough) before setting it to OFALL (processed fallthrough).
Unfortunately, sometimes the fallthrough statement won't be in the
last node. For example, in
case 0:
return func() int {return 1}()
fallthrough
the compiler generates
autotmp_0 = (func literal)(); return autotmp_0; fallthrough; <node VARKILL>
with an OVARKILL node in the last position. casebody will find that
last.Op != OXFALL, won't mark the fallthrough as processed, and the
fallthrough line will cause a "fallthrough statement out of place" error.
To fix this, we change casebody so that it searches for the fallthrough
statement backwards in the statements list, without assuming that it'll
be in the last position.
Fixes#13262
Change-Id: I366c6caa7fd7442d365bd7a08cc66a552212d9b2
Reviewed-on: https://go-review.googlesource.com/22921
Run-TryBot: Quentin Smith <quentin@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
We're dropping this behavior in favor of runtime.KeepAlive.
Implement runtime.KeepAlive as an intrinsic.
Update #15843
Change-Id: Ib60225bd30d6770ece1c3c7d1339a06aa25b1cbc
Reviewed-on: https://go-review.googlesource.com/28310
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
staticassign unwraps all CONVNOPs.
However, in the included test, we need the
CONVNOP for everything to typecheck.
Stop unwrapping unnecessarily.
The code we generate for this example is
suboptimal, but that's not new; see #17113.
Fixes#17111.
Change-Id: I29532787a074a6fe19a5cc53271eb9c84bf1b576
Reviewed-on: https://go-review.googlesource.com/29213
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When possible, emit static data rather than
init functions for interface values.
This:
* cuts 32k off cmd/go
* removes several error values from runtime init
* cuts the size of the image/color/palette compiled package from 103k to 34k
* reduces the time to build the package in #15520 from 8s to 1.5s
Fixes#6289Fixes#15528
Change-Id: I317112da17aadb180c958ea328ab380f83e640b4
Reviewed-on: https://go-review.googlesource.com/26668
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Includes test case shown to fail with unpatched compiler.
Fixes#17005.
Change-Id: I49b7b1a3f02736d85846a2588018b73f68d50320
Reviewed-on: https://go-review.googlesource.com/28573
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
It was fixed earlier in the Go 1.8 cycle.
Add a test.
Fixes#15895
Change-Id: I5834831235d99b9fcf21b435932cdd7ac6dc2c6e
Reviewed-on: https://go-review.googlesource.com/28476
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
make(T, n, m) returns a slice of type T with length n and capacity m
where "The size arguments n and m must be of integer type or untyped."
https://tip.golang.org/ref/spec#Making_slices_maps_and_channels
The failure to reject typed non-integer size arguments in make
during compile time was uncovered after https://golang.org/cl/27851
changed the generation of makeslice calls.
Fixes #16940
Updates #16949
Change-Id: Ib1e3576f0e6ad199c9b16b7a50c2db81290c63b4
Reviewed-on: https://go-review.googlesource.com/28301
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Intrinsified atomic op produces <value,memory>. Make sure this
memory is considered in the store chain calculation.
Fixes#16948.
Change-Id: I029f164b123a7e830214297f8373f06ea0bf1e26
Reviewed-on: https://go-review.googlesource.com/28350
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Generate a for loop for ranging over strings that only needs to call
the runtime function charntorune for non ASCII characters.
This provides faster iteration over ASCII characters and slightly
faster iteration for other characters.
The runtime function charntorune is changed to take an index from where
to start decoding and returns the index after the last byte belonging
to the decoded rune.
All call sites of charntorune in the runtime are replaced by a for loop
that will be transformed by the compiler instead of calling the charntorune
function directly.
go binary size decreases by 80 bytes.
godoc binary size increases by around 4 kilobytes.
runtime:
name old time/op new time/op delta
RuneIterate/range/ASCII-4 43.7ns ± 3% 10.3ns ± 4% -76.33% (p=0.000 n=44+45)
RuneIterate/range/Japanese-4 72.5ns ± 2% 62.8ns ± 2% -13.41% (p=0.000 n=49+50)
RuneIterate/range1/ASCII-4 43.5ns ± 2% 10.4ns ± 3% -76.18% (p=0.000 n=50+50)
RuneIterate/range1/Japanese-4 72.5ns ± 2% 62.9ns ± 2% -13.26% (p=0.000 n=50+49)
RuneIterate/range2/ASCII-4 43.5ns ± 3% 10.3ns ± 2% -76.22% (p=0.000 n=48+47)
RuneIterate/range2/Japanese-4 72.4ns ± 2% 62.7ns ± 2% -13.47% (p=0.000 n=50+50)
strings:
name old time/op new time/op delta
IndexRune-4 64.7ns ± 5% 22.4ns ± 3% -65.43% (p=0.000 n=25+21)
MapNoChanges-4 269ns ± 2% 157ns ± 2% -41.46% (p=0.000 n=23+24)
Fields-4 23.0ms ± 2% 19.7ms ± 2% -14.35% (p=0.000 n=25+25)
FieldsFunc-4 23.1ms ± 2% 19.6ms ± 2% -14.94% (p=0.000 n=25+24)
name old speed new speed delta
Fields-4 45.6MB/s ± 2% 53.2MB/s ± 2% +16.87% (p=0.000 n=24+25)
FieldsFunc-4 45.5MB/s ± 2% 53.5MB/s ± 2% +17.57% (p=0.000 n=25+24)
Updates #13162
Change-Id: I79ffaf828d82bf9887592f08e5cad883e9f39701
Reviewed-on: https://go-review.googlesource.com/27853
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Martin Möhrmann <martisch@uos.de>
Where possible generate calls to runtime makeslice with int arguments
during compile time instead of makeslice with int64 arguments.
This eliminates converting arguments for calls to makeslice with
int64 arguments for platforms where int64 values do not fit into
arguments of type int.
godoc 386 binary shrinks by approximately 12 kilobyte.
amd64:
name old time/op new time/op delta
MakeSlice-2 29.8ns ± 1% 29.8ns ± 1% ~ (p=1.000 n=24+24)
386:
name old time/op new time/op delta
MakeSlice-2 52.3ns ± 0% 45.9ns ± 0% -12.17% (p=0.000 n=25+22)
Fixes #15357
Change-Id: Icb8701bb63c5a83877d26c8a4b78e782ba76de7c
Reviewed-on: https://go-review.googlesource.com/27851
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The compiler was canonicalizing unnamed types of the form
struct { i int }
across packages, even though an unexported field i should not be
accessible from other packages.
The fix requires both qualifying the field name in the string used by
the compiler to distinguish the type, and ensuring the struct's pkgpath
is set in the rtype version of the data when the type being written is
not part of the localpkg.
Fixes#16616
Change-Id: Ibab160b8b5936dfa47b17dbfd48964a65586785b
Reviewed-on: https://go-review.googlesource.com/27791
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL reworks walkcompare for clarity and concision.
It also makes one significant functional change.
(The functional change is hard to separate cleanly
from the cleanup, so I just did them together.)
When inlining and unrolling an equality comparison
for a small struct or array, compare the elements like:
a[0] == b[0] && a[1] == b[1]
rather than
pa := &a
pb := &b
pa[0] == pb[0] && pa[1] == pb[1]
The result is the same, but taking the address
and working through the indirect
forces the backends to generate less efficient code.
This is only an improvement with the SSA backend.
However, every port but s390x now has a working
SSA backend, and switching to the SSA backend
by default everywhere is a priority for Go 1.8.
It thus seems reasonable to start to prioritize
SSA performance over the old backend.
Updates #15303
Sample code:
type T struct {
a, b int8
}
func g(a T) bool {
return a == T{1, 2}
}
SSA before:
"".g t=1 size=80 args=0x10 locals=0x8
0x0000 00000 (badeq.go:7) TEXT "".g(SB), $8-16
0x0000 00000 (badeq.go:7) SUBQ $8, SP
0x0004 00004 (badeq.go:7) FUNCDATA $0, gclocals·23e8278e2b69a3a75fa59b23c49ed6ad(SB)
0x0004 00004 (badeq.go:7) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
0x0004 00004 (badeq.go:8) MOVBLZX "".a+16(FP), AX
0x0009 00009 (badeq.go:8) MOVB AL, "".autotmp_0+6(SP)
0x000d 00013 (badeq.go:8) MOVBLZX "".a+17(FP), AX
0x0012 00018 (badeq.go:8) MOVB AL, "".autotmp_0+7(SP)
0x0016 00022 (badeq.go:8) MOVB $0, "".autotmp_1+4(SP)
0x001b 00027 (badeq.go:8) MOVB $1, "".autotmp_1+4(SP)
0x0020 00032 (badeq.go:8) MOVB $2, "".autotmp_1+5(SP)
0x0025 00037 (badeq.go:8) MOVBLZX "".autotmp_0+6(SP), AX
0x002a 00042 (badeq.go:8) MOVBLZX "".autotmp_1+4(SP), CX
0x002f 00047 (badeq.go:8) CMPB AL, CL
0x0031 00049 (badeq.go:8) JNE 70
0x0033 00051 (badeq.go:8) MOVBLZX "".autotmp_0+7(SP), AX
0x0038 00056 (badeq.go:8) CMPB AL, $2
0x003a 00058 (badeq.go:8) SETEQ AL
0x003d 00061 (badeq.go:8) MOVB AL, "".~r1+24(FP)
0x0041 00065 (badeq.go:8) ADDQ $8, SP
0x0045 00069 (badeq.go:8) RET
0x0046 00070 (badeq.go:8) MOVB $0, AL
0x0048 00072 (badeq.go:8) JMP 61
SSA after:
"".g t=1 size=32 args=0x10 locals=0x0
0x0000 00000 (badeq.go:7) TEXT "".g(SB), $0-16
0x0000 00000 (badeq.go:7) NOP
0x0000 00000 (badeq.go:7) NOP
0x0000 00000 (badeq.go:7) FUNCDATA $0, gclocals·23e8278e2b69a3a75fa59b23c49ed6ad(SB)
0x0000 00000 (badeq.go:7) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
0x0000 00000 (badeq.go:8) MOVBLZX "".a+8(FP), AX
0x0005 00005 (badeq.go:8) CMPB AL, $1
0x0007 00007 (badeq.go:8) JNE 25
0x0009 00009 (badeq.go:8) MOVBLZX "".a+9(FP), CX
0x000e 00014 (badeq.go:8) CMPB CL, $2
0x0011 00017 (badeq.go:8) SETEQ AL
0x0014 00020 (badeq.go:8) MOVB AL, "".~r1+16(FP)
0x0018 00024 (badeq.go:8) RET
0x0019 00025 (badeq.go:8) MOVB $0, AL
0x001b 00027 (badeq.go:8) JMP 20
Change-Id: I120185d58012b7bbcdb1ec01225b5b08d0855d86
Reviewed-on: https://go-review.googlesource.com/22277
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Blank struct fields are regular unexported fields. Two
blank fields are different if they are from different
packages. In order to correctly differentiate them, the
compiler needs the package information. Add it to the
export data.
Fixes#15514.
Change-Id: I421aaca22b542fcd0d66b2d2db777249cad78df6
Reviewed-on: https://go-review.googlesource.com/27639
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change-Id: I4faf9a55414e217f0c48528efb13ab8fdcd9bb16
Reviewed-on: https://go-review.googlesource.com/24845
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Add a type conversion to uintptr for untyped constants
before the conversion to unsafe.Pointer.
Fixes#16317
Change-Id: Ib85feccad1019e687e7eb6135890b64b82fb87fb
Reviewed-on: https://go-review.googlesource.com/27441
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This makes a bunch of changes to package syntax to tweak line numbers
for AST nodes. For example, short variable declaration statements are
now associated with the location of the ":=" token, and function calls
are associated with the location of the final ")" token. These help
satisfy many unit tests that assume the old parser's behavior.
Because many of these changes are questionable, they're guarded behind
a new "gcCompat" const to make them easy to identify and revisit in
the future.
A handful of remaining tests are too difficult to make behave
identically. These have been updated to execute with -newparser=0 and
comments explaining why they need to be fixed.
all.bash now passes with both the old and new parsers.
Change-Id: Iab834b71ca8698d39269f261eb5c92a0d55a3bf4
Reviewed-on: https://go-review.googlesource.com/27199
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This time with the cherry-pick from the proper patch of
the old CL.
Stack size increased.
Corrected NaN-comparison glitches.
Marked g register as clobbered by calls.
Fixed shared libraries.
live_ssa.go still disabled because of differences.
Presumably turning on more optimization will fix
both the stack size and the live_ssa.go glitches.
Enhanced debugging output for shared libs test.
Rebased onto master.
Updates #16010.
Change-Id: I40864faf1ef32c118fb141b7ef8e854498e6b2c4
Reviewed-on: https://go-review.googlesource.com/27159
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In CSE if a tuple generator is CSE'd to a different block, its
selectors are copied to the same block. In this case, also CES
the copied selectors.
Test copied from Keith's CL 27202.
Fixes#16741.
Change-Id: I2fc8b9513d430f10d6104275cfff5fb75d3ef3d9
Reviewed-on: https://go-review.googlesource.com/27236
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Don't fold constant factors into a multiply
beyond the capacity of a MULQ instruction (32 bits).
Fixes#16733
Change-Id: Idc213c6cb06f7c94008a8cf9e60a9e77d085fd89
Reviewed-on: https://go-review.googlesource.com/27160
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
SSA compiler on AMD64 may spill Duff-adjusted address as scalar. If
the object is on stack and the stack moves, the spilled address become
invalid.
Making the spill pointer-typed does not work. The Duff-adjusted address
points to the memory before the area to be zeroed and may be invalid.
This may cause stack scanning code panic.
Fix it by doing Duff-adjustment in genValue, so the intermediate value
is not seen by the reg allocator, and will not be spilled.
Add a test to cover both cases. As it depends on allocation, it may
be not always triggered.
Fixes#16515.
Change-Id: Ia81d60204782de7405b7046165ad063384ede0db
Reviewed-on: https://go-review.googlesource.com/25309
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
If we don't mark them as needzero, we have a live pointer variable
containing possible garbage, which will baffle the GC.
Fixes#16249.
Change-Id: I7c423ceaca199ddd46fc2c23e5965e7973f07584
Reviewed-on: https://go-review.googlesource.com/24715
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The compiler was treating all global function literals as occurring in a
function named "glob", which caused a symbol name collision when there
was an actual function named "glob". Fixed by adding a period.
Fixes#16193.
Change-Id: I67792901a8ca04635ba41d172bfaee99944f594d
Reviewed-on: https://go-review.googlesource.com/24500
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Make sure the pointer to the heap copy of an output parameter is kept
live throughout the function. The function could panic at any point,
and then a defer could recover. Thus, we need the pointer to the heap
copy always available so the post-deferreturn code can copy the return
value back to the stack.
Before this CL, the pointer to the heap copy could be considered dead in
certain situations, like code which is reverse dominated by a panic call.
Fixes#16095.
Change-Id: Ic3800423e563670e5b567b473bf4c84cddb49a4c
Reviewed-on: https://go-review.googlesource.com/24213
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This is a regression from 1.6. The respective code in importimport
(export.go) was not exactly replicated with the new importer. Also
copied over the missing cyclic import check.
Added test cases.
Fixes#16133.
Change-Id: I1e0a39ff1275ca62a8054874294d400ed83fb26a
Reviewed-on: https://go-review.googlesource.com/24312
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
A straight conversion from a type T to an interface type I, where T does
not implement I, should always panic with an interface conversion error
that shows the missing method. This was not happening if the conversion
was done once using the comma-ok form (the result would not be OK) and
then again in a straight conversion. Due to an error in the runtime
package the second conversion was failing with a nil pointer
dereference.
Fixes#16130.
Change-Id: I8b9fca0f1bb635a6181b8b76de8c2385bb7ac2d2
Reviewed-on: https://go-review.googlesource.com/24284
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michel Lespinasse <walken@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This adds 8 bytes of binary size to every type that has methods. It is
the smallest change I could come up with for 1.7.
Fixes#16037
Change-Id: Ibe15c3165854a21768596967757864b880dbfeed
Reviewed-on: https://go-review.googlesource.com/24070
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Special case for rewriting OAS inits omitted OASWB, added
that and OAS2FUNC. The special case cannot be default case,
that causes racewalk to fail in horrible ways.
Fixes#16008.
Change-Id: Ie0d2f5735fe9d8255a109597b36d196d4f86703a
Reviewed-on: https://go-review.googlesource.com/23954
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The generated code for interface stubs sometimes just messes
with a few of the args and then tail-calls to the target routine.
The args that aren't explicitly modified appear to not be used.
But they are used, by the thing we're tail calling.
Fixes#16016
Change-Id: Ib9b3a8311bb714a201daee002885fcb59e0463fa
Reviewed-on: https://go-review.googlesource.com/23960
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This matches the behavior of the legacy backend.
Fixes#15975 (if this is the intended behavior)
Change-Id: Id277959069b8b8bf9958fa8f2cbc762c752a1a19
Reviewed-on: https://go-review.googlesource.com/23820
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Post-liveness fix, the slices on both sides can now be
indirects of & variables. The cgen code handles those
cases just fine.
Fixes#15988
Change-Id: I378ad1d5121587e6107a9879c167291a70bbb9e4
Reviewed-on: https://go-review.googlesource.com/23863
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Make sure auto names don't conflict with function names. Before this CL,
we confused name a.len (the len field of the slice a) with a.len (the function
len declared on a).
Fixes#15961
Change-Id: I14913de697b521fb35db9a1b10ba201f25d552bb
Reviewed-on: https://go-review.googlesource.com/23789
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Adding a .def suffix for DWARF info collided with the DWARF info,
without the suffix, for a method named def. Change the suffix to ..def
instead.
Fixes#15926.
Change-Id: If1bf1bcb5dff1d7f7b79f78e3f7a3bbfcd2201bb
Reviewed-on: https://go-review.googlesource.com/23733
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
If memory might be unaligned, zero it one byte at a time
instead of 4 bytes at a time.
Fixes#15902
Change-Id: I4eff0840e042e2f137c1a4028f08793eb7dfd703
Reviewed-on: https://go-review.googlesource.com/23587
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
The liveness computation of parameters generally was never
correct, but forcing all parameters to be live throughout the
function covered up that problem. The new SSA back end is
too clever: even though it currently keeps the parameter values live
throughout the function, it may find optimizations that mean
the current values are not written back to the original parameter
stack slots immediately or ever (for example if a parameter is set
to nil, SSA constant propagation may replace all later uses of the
parameter with a constant nil, eliminating the need to write the nil
value back to the stack slot), so the liveness code must now
track the actual operations on the stack slots, exposing these
problems.
One small problem in the handling of arguments is that nodarg
can return ONAME PPARAM nodes with adjusted offsets, so that
there are actually multiple *Node pointers for the same parameter
in the instruction stream. This might be possible to correct, but
not in this CL. For now, we fix this by using n.Orig instead of n
when considering PPARAM and PPARAMOUT nodes.
The major problem in the handling of arguments is general
confusion in the liveness code about the meaning of PPARAM|PHEAP
and PPARAMOUT|PHEAP nodes, especially as contrasted with PAUTO|PHEAP.
The difference between these two is that when a local variable "moves"
to the heap, it's really just allocated there to start with; in contrast,
when an argument moves to the heap, the actual data has to be copied
there from the stack at the beginning of the function, and when a
result "moves" to the heap the value in the heap has to be copied
back to the stack when the function returns
This general confusion is also present in the SSA back end.
The PHEAP bit worked decently when I first introduced it 7 years ago (!)
in 391425ae. The back end did nothing sophisticated, and in particular
there was no analysis at all: no escape analysis, no liveness analysis,
and certainly no SSA back end. But the complications caused in the
various downstream consumers suggest that this should be a detail
kept mainly in the front end.
This CL therefore eliminates both the PHEAP bit and even the idea of
"heap variables" from the back ends.
First, it replaces the PPARAM|PHEAP, PPARAMOUT|PHEAP, and PAUTO|PHEAP
variable classes with the single PAUTOHEAP, a pseudo-class indicating
a variable maintained on the heap and available by indirecting a
local variable kept on the stack (a plain PAUTO).
Second, walkexpr replaces all references to PAUTOHEAP variables
with indirections of the corresponding PAUTO variable.
The back ends and the liveness code now just see plain indirected
variables. This may actually produce better code, but the real goal
here is to eliminate these little-used and somewhat suspect code
paths in the back end analyses.
The OPARAM node type goes away too.
A followup CL will do the same to PPARAMREF. I'm not sure that
the back ends (SSA in particular) are handling those right either,
and with the framework established in this CL that change is trivial
and the result clearly more correct.
Fixes#15747.
Change-Id: I2770b1ce3cbc93981bfc7166be66a9da12013d74
Reviewed-on: https://go-review.googlesource.com/23393
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The importer had several bugs with respect to labels and gotos:
- it didn't create a new ONAME node for label names (label dcl,
goto, continue, and break)
- it overwrote the symbol for gotos with the dclstack
- it didn't set the dclstack for labels
In the process changed export format slightly to always assume
a label name for labels and gotos, and never assume a label for
fallthroughs.
For fallthroughs and switch cases, now also set Xoffset like in
the parser. (Not setting it, i.e., using 0 was ok since this is
only used for verifying correct use of fallthroughs, which was
checked already. But it's an extra level of verification of the
import.)
Fixes#15838.
Change-Id: I3637f6314b8651c918df0c8cd70cd858c92bd483
Reviewed-on: https://go-review.googlesource.com/23445
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 21462 and CL 21463 made this message say explicitly that the problem
was a struct field in a map, but the word "directly" is unnecessary,
sounds wrong, and makes the error long.
Change-Id: I2fb68cdaeb8bd94776b8022cf3eae751919ccf6f
Reviewed-on: https://go-review.googlesource.com/23373
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Non-syntax errors are always counted to determine if to exit
early, but then deduplication eliminates them. This can lead
to situations which report "too many errors" and only one
error is shown.
De-duplicate non-syntax errors early, at least the ones that
appear consecutively, and only count the ones actually being
shown. This doesn't work perfectly as they may not appear in
sequence, but it's cheap and good enough.
Fixes#14136.
Change-Id: I7b11ebb2e1e082f0d604b88e544fe5ba967af1d7
Reviewed-on: https://go-review.googlesource.com/23259
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
They get rewritten to NEWs, and they must be marked as escaping
so walk doesn't try to allocate them back onto the stack.
Fixes#15733
Change-Id: I433033e737c3de51a9e83a5a273168dbc9110b74
Reviewed-on: https://go-review.googlesource.com/23223
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
