This CL substantially reworks how imported declarations are handled,
and fixes a number of issues with dot imports. In particular:
1. It eliminates the stub ir.Name declarations that are created
upfront during import-declaration processing, allowing this to be
deferred to when the declarations are actually needed. (Eventually,
this can be deferred even further so we never have to create ir.Names
w/ ONONAME, but this CL is already invasive/subtle enough.)
2. During noding, we now use ir.Idents to represent uses of imported
declarations, including of dot-imported declarations.
3. Unused dot imports are now reported after type checking, so that we
can correctly distinguish whether composite literal keys are a simple
identifier (struct literals) or expressions (array/slice/map literals)
and whether it might be a use of a dot-imported declaration.
4. It changes the "redeclared" error messages to report the previous
position information in the same style as other compiler error
messages that reference other source lines.
Passes buildall w/ toolstash -cmp.
Fixes#6428.
Fixes#43164.
Fixes#43167.
Updates #42990.
Change-Id: I40a0a780ec40daf5700fbc3cfeeb7300e1055981
Reviewed-on: https://go-review.googlesource.com/c/go/+/277713
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
There were only a few places these were still used, none of which
justify generating all this code. Instead rewrite them to use
fmt.Sprint or simpler means.
Passes buildall w/ toolstash -cmp.
Change-Id: Ibd123a1696941a597f0cb4dcc96cda8ced672140
Reviewed-on: https://go-review.googlesource.com/c/go/+/276072
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
It just makes the compiler crash. Oops.
Fixes#43099
Change-Id: Id996c14799c1a5d0063ecae3b8770568161c2440
Reviewed-on: https://go-review.googlesource.com/c/go/+/276652
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Ending typecheck1 in the switch makes it safe for each case
to do an appropriate type assertion. The main change is dropping
the computation of "ok" and using the syntax nodes themselves
to decide what's OK.
Passes buildall w/ toolstash -cmp.
Change-Id: I2a1873a51e3f1194d74bb87a6653cb9857a02a1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/275444
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The gofrontend code would in some circumstances incorrectly generate a
type descriptor for an alias type, causing the type to fail to be
equal to the unaliased type.
Change-Id: I47d33b0bfde3c72a9a186049539732bdd5a6a96e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275632
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If an interface contains a blank method, that's already an error. No
need for useless follow-up error messages about not implementing them.
Fixes#42964.
Change-Id: I5bf53a8f27d75d4c86c61588c5e2e3e95563d320
Reviewed-on: https://go-review.googlesource.com/c/go/+/275294
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
An address of offset(SP) may point to the callee args area, and
may be used to move things into/out of the args/results. If an
address like that is spilled and picked up by the GC, it may hold
an arg/result live in the callee, which may not actually be live
(e.g. a result not initialized at function entry). Make sure
they are rematerializeable, so they are always short-lived and
never picked up by the GC.
This CL changes 386, PPC64, and Wasm. On AMD64 we already have
the rule (line 2159). On other architectures, we already have
similar rules like
(OffPtr [off] ptr:(SP)) => (MOVDaddr [int32(off)] ptr)
to avoid this problem. (Probably me in the past had run into
this...)
Fixes#42944.
Change-Id: Id2ec73ac08f8df1829a9a7ceb8f749d67fe86d1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275174
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
assign.go:59:28: error: ‘x’ repeated on left side of :=
assign.go:65:20: error: ‘a’ repeated on left side of :=
method2.go:36:11: error: reference to method ‘val’ in type that is pointer to interface, not interface
method2.go:37:11: error: reference to method ‘val’ in type that is pointer to interface, not interface
Change-Id: I8f385c75a82fae4eacf4618df8f9f65932826494
Reviewed-on: https://go-review.googlesource.com/c/go/+/274447
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Now that filepath.WalkDir is available, it is more efficient
and should be used in place of filepath.Walk.
Update the tree to reflect best practices.
As usual, the code compiled with Go 1.4 during bootstrap is excluded.
(In this CL, that's only cmd/dist.)
For #42027.
Change-Id: Ib0f7b1e43e50b789052f9835a63ced701d8c411c
Reviewed-on: https://go-review.googlesource.com/c/go/+/267719
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
It's noisy and not doing any harm, and we still have an entire release
cycle to revisit and address the issue properly.
Updates #42938
Change-Id: I1de5cfb495a8148c9c08b215deba38f2617fb467
Reviewed-on: https://go-review.googlesource.com/c/go/+/274732
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The gofrontend code doesn't distinguish semicolon and newline,
and it doesn't have special treatment for EOF.
syntax/semi6.go:9:47: error: unexpected semicolon or newline in type declaration
syntax/semi6.go:11:62: error: unexpected semicolon or newline in type declaration
Change-Id: I9996b59a4fc78ad1935e779f354ddf75c0fb44e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/274692
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
These replacement rules assume that TST and TEQ set V. But TST and
TEQ do not set V. This is a problem because instructions like LT are
actually checking for N!=V. But with TST and TEQ not setting V, LT
doesn't do anything meaningful. It's possible to construct trivial
miscompilations from this, such as:
package main
var x = [4]int32{-0x7fffffff, 0x7fffffff, 2, 4}
func main() {
if x[0] > x[1] {
panic("fail 1")
}
if x[2]&x[3] < 0 {
panic("fail 2") // Fails here
}
}
That first comparison sets V, via the CMP that subtracts the values
causing the overflow. Then the second comparison operation thinks that
it uses the result of TST, when it actually uses the V from CMP.
Before this fix:
TST R0, R1
BLT loc_6C164
After this fix:
TST R0, R1
BMI loc_6C164
The BMI instruction checks the N flag, which TST sets. This commit
fixes the issue by using [LG][TE]noov instead of vanilla [LG][TE], and
also adds a test case for the direct issue.
Fixes#42876.
Change-Id: I13c62c88d18574247ad002b671b38d2d0b0fc6fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/274026
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
There's not really any use to tracking function-scoped constants and
types on Curfn.Dcl, and there's sloppy code that assumes all of the
declarations are variables (e.g., cmpstackvarlt).
Change-Id: I5d10dc681dac2c161c7b73ba808403052ca0608e
Reviewed-on: https://go-review.googlesource.com/c/go/+/274436
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
The code for type-checking defined types was scattered between
typecheckdef, typecheckdeftype, and setUnderlying. There was redundant
work between them, and setUnderlying also needed to redo a lot of work
because of its brute-force solution of just copying all Type fields.
This CL reorders things so as many of the defined type's fields are
set in advance (in typecheckdeftype), and then setUnderlying only
copies over the details actually needed from the underlying type.
Incidentally, this evidently improves our error handling for an
existing test case, by allowing us to report an additional error.
Passes toolstash/buildall.
Change-Id: Id59a24341e7e960edd1f7366c3e2356da91b9fe7
Reviewed-on: https://go-review.googlesource.com/c/go/+/274432
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Allows emitting errors about ineffectual //go:linkname directives.
In particular, this exposed: a typo in os2_aix.go; redundant (but
harmless) directives for libc_pipe in both os3_solaris.go and
syscall2_solaris.go; and a bunch of useless //go:linkname directives
in macOS wrapper code.
However, because there's also ineffectual directives in the vendored
macOS code from x/sys, that can't be an error just yet. So instead we
print a warning (including a heads up that it will be promoted to an
error in Go 1.17) to prevent backsliding while we fix and re-vendor
that code.
Passes toolstash-check.
Change-Id: I59badeab5df0d8b3abfd14c6066e9bb00e840f73
Reviewed-on: https://go-review.googlesource.com/c/go/+/273986
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
This matches the error messages after CL 273890.
syntax/semi4.go:11:9: error: unexpected semicolon or newline, expecting ‘{’ after for clause
syntax/semi4.go:10:13: error: reference to undefined name ‘x’
syntax/semi4.go:12:17: error: reference to undefined name ‘z’
Change-Id: Ic88ff6e27d50bf70f5b2114383b84c42c0682f39
Reviewed-on: https://go-review.googlesource.com/c/go/+/273891
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
shift1.go:76:16: error: shift of non-integer operand
shift1.go:77:16: error: shift of non-integer operand
Change-Id: I48584c0b01f9f6912a93b5f9bba55b5803fbeced
Reviewed-on: https://go-review.googlesource.com/c/go/+/273888
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
As of https://golang.org/cl/273886:
fixedbugs/bug340.go:15:18: error: reference to method ‘x’ in interface with no methods
For golang/go#10700
Change-Id: Id29eb0e34bbb524117614229c4c27cfd17dae286
Reviewed-on: https://go-review.googlesource.com/c/go/+/273887
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
These changes match the following gofrontend error messages:
blank1.go:16:1: error: may not define methods on non-local type
chan/perm.go:28:9: error: expected channel
chan/perm.go:29:11: error: left operand of ‘<-’ must be channel
chan/perm.go:69:9: error: argument must be channel
complit1.go:25:16: error: attempt to slice object that is not array, slice, or string
complit1.go:26:16: error: attempt to slice object that is not array, slice, or string
complit1.go:27:17: error: attempt to slice object that is not array, slice, or string
complit1.go:49:41: error: may only omit types within composite literals of slice, array, or map type
complit1.go:50:14: error: expected struct, slice, array, or map type for composite literal
convlit.go:24:9: error: invalid type conversion (cannot use type unsafe.Pointer as type string)
convlit.go:25:9: error: invalid type conversion (cannot use type unsafe.Pointer as type float64)
convlit.go:26:9: error: invalid type conversion (cannot use type unsafe.Pointer as type int)
ddd1.go:63:9: error: invalid use of ‘...’ calling non-variadic function
fixedbugs/bug176.go:12:18: error: index expression is not integer constant
fixedbugs/bug332.go:17:10: error: use of undefined type ‘T’
fixedbugs/issue4232.go:22:16: error: integer constant overflow
fixedbugs/issue4232.go:33:16: error: integer constant overflow
fixedbugs/issue4232.go:44:25: error: integer constant overflow
fixedbugs/issue4232.go:55:16: error: integer constant overflow
fixedbugs/issue4458.go:19:14: error: type has no method ‘foo’
fixedbugs/issue5172.go:24:14: error: too many expressions for struct
init.go:17:9: error: reference to undefined name ‘runtime’
initializerr.go:26:29: error: duplicate value for index 1
interface/explicit.go:60:14: error: type assertion only valid for interface types
label.go:64:9: error: reference to undefined label ‘go2’
label1.go:18:97: error: continue statement not within for
label1.go:22:97: error: continue statement not within for
label1.go:106:89: error: continue statement not within for
label1.go:108:26: error: invalid continue label ‘on’
label1.go:111:118: error: break statement not within for or switch or select
label1.go:113:23: error: invalid break label ‘dance’
map1.go:64:9: error: not enough arguments
map1.go:65:9: error: not enough arguments
map1.go:67:9: error: argument 1 must be a map
method2.go:36:11: error: reference to undefined field or method ‘val’
method2.go:37:11: error: reference to undefined field or method ‘val’
method2.go:41:12: error: method requires pointer (use ‘(*T).g’)
syntax/chan1.go:13:19: error: send statement used as value; use select for non-blocking send
syntax/chan1.go:17:11: error: send statement used as value; use select for non-blocking send
Change-Id: I98047b60a376e3d2788836300f7fcac3f2c285cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/273527
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In the previous CL, I had incorrectly removed one of the error
messages from issue20232.go, because I thought go/constant was just
handling it. But actually the compiler was panicking in nodlit,
because it didn't handle constant.Unknown. So this CL makes it leave
n.Type == nil for unknown constant.Values.
While here, also address #42732 by making sure to report an error
message when origConst is called with an unknown constant.Value (as
can happen when multiplying two floating-point constants overflows).
Finally, add OXOR and OBITNOT to the list of operations to report
errors about, since they're also constant expressions that can produce
a constant with a greater bit length than their operands.
Fixes#42732.
Change-Id: I4a538fbae9b3ac4c553d7de5625dc0c87d9acce3
Reviewed-on: https://go-review.googlesource.com/c/go/+/272928
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Address outstanding TODO, which simplifies subsequent CLs.
Now the compiler always type checks type-switch case clauses (like
gccgo), but it treats clause variables as broken if an appropriate
type cannot be determined for it (like go/types).
Passes toolstash-check.
Change-Id: Iedfe9cdf38c6865211e4b93391f1cf72c1bed136
Reviewed-on: https://go-review.googlesource.com/c/go/+/272648
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
CL 271906 allows loading single field of typed-interface{} OpIData, but
it does not update the corresponding selector type. So the generated
OpLoad has the named type instead, prevent it from being lowered by
lower pass.
Fixes#42784
Change-Id: Idf32e4f711731be09d508dd712b60bc8c58309bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/272466
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The bug was introduced by https://golang.org/cl/220844.
Fixes#42790.
Change-Id: I44d619a1a4d3f2aee1c5575d5cfddcc4ba10895f
Reviewed-on: https://go-review.googlesource.com/c/go/+/272666
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This issue was already fixed at tip. Just adding the test that
failed on 1.14/1.15.
Update #42753
Change-Id: I00d13ade476b9c17190d762d7fdcb30cf6c83954
Reviewed-on: https://go-review.googlesource.com/c/go/+/272029
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Same reason as CL 270057, but for OpLoad.
Fixes#42727
Change-Id: Iebb1a8110f29427a0aed3b5e3e84f0540de3d1b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/271906
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
When inlining a function call expression, it's possible that the
function callee subexpression has side effects that need to be
preserved. This used to not be an issue, because inlining wouldn't
recognize these as inlinable anyway. But golang.org/cl/266199 extended
the inlining logic to recognize more cases, but did not notice that
the actual inlining code was discarding side effects.
Issue identified by danscales@.
Fixes#42703.
Change-Id: I95f8fc076b6ca4e9362e80ec26dad9d87a5bc44a
Reviewed-on: https://go-review.googlesource.com/c/go/+/271219
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Within the frontend, we generally don't guarantee uniqueness of
anonymous types. For example, each struct type literal gets
represented by its own types.Type instance.
However, the field tracking code was using the struct type as a map
key. This broke in golang.org/cl/256457, because that CL started
changing the inlined parameter variables from using the types.Type of
the declared parameter to that of the call site argument. These are
always identical types (e.g., types.Identical would report true), but
they can be different pointer values, causing the map lookup to fail.
The easiest fix is to simply get rid of the map and instead use
Node.Opt for tracking the types.Field. To mitigate against more latent
field tracking failures (e.g., if any other code were to start trying
to use Opt on ODOT/ODOTPTR fields), we store this field
unconditionally. I also expect having the types.Field will be useful
to other frontend code in the future.
Finally, to make it easier to test field tracking without having to
run make.bash with GOEXPERIMENT=fieldtrack, this commit adds a
-d=fieldtrack flag as an alternative way to enable field tracking
within the compiler. See also #42681.
Fixes#42686.
Change-Id: I6923d206d5e2cab1e6798cba36cae96c1eeaea55
Reviewed-on: https://go-review.googlesource.com/c/go/+/271217
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Some rules for PPC64 were checking for a case
where a shift followed by an 'and' of a mask could
be lowered, depending on the format of the mask. The
function to verify if the mask was valid for this purpose
was not checking if the mask was 0 which we don't want to
allow. This case can happen if previous optimizations
resulted in that mask value.
This fixes isPPC64ValidShiftMask to check for a mask of 0 and return
false.
This also adds a codegen testcase to verify it doesn't try to
match the rules in the future.
Fixes#42610
Change-Id: I565d94e88495f51321ab365d6388c01e791b4dbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/270358
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
mips SRA/SLL/SRL shift amounts are used mod 32; this change aligns the
XXXconst rules to mask the shift amount by &31.
Passes
$ GOARCH=mips go build -toolexec 'toolstash -cmp' -a std
$ GOARCH=mipsle go build -toolexec 'toolstash -cmp' -a std
Fixes#42587
Change-Id: I6003ebd0bc500fba4cf6fb10254e1b557bf8c48f
Reviewed-on: https://go-review.googlesource.com/c/go/+/270117
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In certain cases, the declkared type of an OpIData is interface{}.
This was not expected (since interface{} is a pair, right?) and
thus caused a crash. What is intended is that these be treated as
a byteptr, so do that instead (this is what happens in 1.15).
Fixes#42568.
Change-Id: Id7c9e5dc2cbb5d7c71c6748832491ea62b0b339f
Reviewed-on: https://go-review.googlesource.com/c/go/+/270057
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
When a variable symbol is both imported (possibly through
inlining) and linkname'd, make sure its LSym is marked as
non-package for symbol indexing in the object file, so it is
resolved by name and dedup'd with the original definition.
Fixes#42401.
Change-Id: I8e90c0418c6f46a048945c5fdc06c022b77ed68d
Reviewed-on: https://go-review.googlesource.com/c/go/+/268178
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Fixes#42445
Change-Id: I9653ef094dba2a1ac2e3daaa98279d10df17a2a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/268257
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Trust: Martin Möhrmann <moehrmann@google.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
CL 244579 added guard clauses to prevent a faulty state that was
possible under the incorrect logic of the uniquePred loop in
addLocalInductiveFacts. That faulty state was still making the
intended optimization, but not for the correct reason.
Removing the faulty state also removed the overly permissive application
of the optimization, and therefore made these two tests fail.
We disabled the tests of this optimization in CL 244579 to allow us to
quickly apply the fix in the CL. This CL now corrects the logic of the
uniquePred loop in order to apply the optimization correctly.
The comment above the uniquePred loop says that it will follow unique
predecessors until it reaches a join point. Without updating the child
node on each iteration, it cannot follow the chain of unique
predecessors more than one step. Adding the update to the child node
on each iteration of the loop allows the logic to follow the chain of
unique predecessors until reaching a join point (because a non-unique
predecessor will signify a join point).
Updates #40502.
Change-Id: I23d8367046a2ab3ce4be969631f9ba15dc533e6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/246157
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
This CL adds support for inlining type switches, including exporting
and importing them.
Type switches are represented mostly the same as expression switches.
However, if the type switch guard includes a short variable
declaration, then there are two differences: (1) there's an ONONAME
(in the OTYPESW's Left) to represent the overall pseudo declaration;
and (2) there's an ONAME (in each OCASE's Rlist) to represent the
per-case variables.
For simplicity, this CL simply writes out each variable separately
using iimport/iiexport's normal Vargen mechanism for disambiguating
identically named variables within a function. This could be improved
somewhat, but inlinable type switches are probably too uncommon to
merit the complexity.
While here, remove "case OCASE" from typecheck1. We only type check
"case" clauses as part of a "select" or "switch" statement, never as
standalone statements.
Fixes#37837
Change-Id: I8f42f6c9afdd821d6202af4a6bf1dbcbba0ef424
Reviewed-on: https://go-review.googlesource.com/c/go/+/266203
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Optimize combinations of left and right shifts by a constant value
into a 'rotate then insert selected bits [into zero]' instruction.
Use the same instruction for contiguous masks since it has some
benefits over 'and immediate' (not restricted to 32-bits, does not
overwrite source register).
To keep the complexity of this change under control I've only
implemented 64 bit operations for now.
There are a lot more optimizations that can be done with this
instruction family. However, since their function overlaps with other
instructions we need to be somewhat careful not to break existing
optimization rules by creating optimization dead ends. This is
particularly true of the load/store merging rules which contain lots
of zero extensions and shifts.
This CL does interfere with the store merging rules when an operand
is shifted left before it is stored:
binary.BigEndian.PutUint64(b, x << 1)
This is unfortunate but it's not critical and somewhat complex so
I plan to fix that in a follow up CL.
file before after Δ %
addr2line 4117446 4117282 -164 -0.004%
api 4945184 4942752 -2432 -0.049%
asm 4998079 4991891 -6188 -0.124%
buildid 2685158 2684074 -1084 -0.040%
cgo 4553732 4553394 -338 -0.007%
compile 19294446 19245070 -49376 -0.256%
cover 4897105 4891319 -5786 -0.118%
dist 3544389 3542785 -1604 -0.045%
doc 3926795 3927617 +822 +0.021%
fix 3302958 3293868 -9090 -0.275%
link 6546274 6543456 -2818 -0.043%
nm 4102021 4100825 -1196 -0.029%
objdump 4542431 4548483 +6052 +0.133%
pack 2482465 2416389 -66076 -2.662%
pprof 13366541 13363915 -2626 -0.020%
test2json 2829007 2761515 -67492 -2.386%
trace 10216164 10219684 +3520 +0.034%
vet 6773956 6773572 -384 -0.006%
total 107124151 106917891 -206260 -0.193%
Change-Id: I7591cce41e06867ba10a745daae9333513062746
Reviewed-on: https://go-review.googlesource.com/c/go/+/233317
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Michael Munday <mike.munday@ibm.com>
We already remove racefuncenter and racefuncexit if they are not
needed (i.e. the function doesn't have any other race calls).
racefuncenterfp is like racefuncenter but used on LR machines.
Remove unnecessary racefuncenterfp as well.
Change-Id: I65edb00e19c6d9ab55a204cbbb93e9fb710559f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/267099
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
In golang.org/cl/266199, I reused the existing code in inlining that
recognizes anonymous variables. However, it turns out that code
mistakenly recognizes anonymous return parameters as named when
inlining a function from the same package.
The issue is funcargs (which is only used for functions parsed from
source) synthesizes ~r names for anonymous return parameters, but
funcargs2 (which is only used for functions imported from export data)
does not.
This CL fixes the behavior so that anonymous return parameters are
handled identically whether a function is inlined within the same
package or across packages. It also adds a proper cross-package test
case demonstrating #33160 is fixed in both cases.
Change-Id: Iaa39a23f5666979a1f5ca6d09fc8c398e55b784c
Reviewed-on: https://go-review.googlesource.com/c/go/+/266719
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
reassignVisitor was short-circuiting on assignment statements after
checking the LHS, but there might be further assignment statements
nested within the RHS expressions.
Fixes#42284.
Change-Id: I175eef87513b973ed5ebe6a6527adb9766dde6cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/266618
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
A method selector expression can pick out a method or promoted method
(represented by ODOTMETH), but it can also pick out an interface
method from an embedded interface-typed field (represented by
ODOTINTER).
In the case that we're picking out an interface method, we're not able
to fully devirtualize the method call. However, we're still able to
improve escape analysis somewhat. E.g., the included test case
demonstrates that we can optimize "i.M()" to "i.(T).I.M()", which
means the T literal can be stack allocated instead of heap allocated.
Fixes#42279.
Change-Id: Ifa21d19011e2f008d84f9624b7055b4676b6d188
Reviewed-on: https://go-review.googlesource.com/c/go/+/266300
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
After inlining, add a pass that looks for interface calls where we can
statically determine the interface value's concrete type. If such a
case is found, insert an explicit type assertion to the concrete type
so that escape analysis can see it.
Fixes#33160.
Change-Id: I36932c691693f0069e34384086d63133e249b06b
Reviewed-on: https://go-review.googlesource.com/c/go/+/264837
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The inlining pass previously bailed upon encountering a go or defer statement, so it would not inline functions e.g. used to provide arguments to the deferred function. This change preserves the behavior of not inlining the
deferred function itself, but it allows the inlining walk to proceed into its arguments.
Fixes#42194
Change-Id: I4e82029d8dcbe69019cc83ae63a4b29af45ec777
Reviewed-on: https://go-review.googlesource.com/c/go/+/264997
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
With previous CLs, internal linking without cgo should work well.
Enable it by default. And stop always requiring cgo.
Enable tests that were previously disabled due to the lack of
internal linking.
Updates #38485.
Change-Id: I45125b9c263fd21d6847aa6b14ecaea3a2989b29
Reviewed-on: https://go-review.googlesource.com/c/go/+/265121
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
pointers to go:notinheap types should be treated as scalars. That
means they shouldn't be stored directly in interfaces, or directly
in reflect.Value.ptr.
Also be sure to use uintpr to compare such pointers in reflect.DeepEqual.
Fixes#42076
Change-Id: I53735f6d434e9c3108d4940bd1bae14c61ef2a74
Reviewed-on: https://go-review.googlesource.com/c/go/+/264480
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
storeType splits compound stores up into a scalar parts and a pointer parts.
The scalar part happens unconditionally, and the pointer part happens
under the guard of a write barrier check.
Types which are declared as pointers, but are represented as scalars because
they might have "bad" values, were not handled correctly here. They ended
up not getting stored in either set.
Fixes#42032
Change-Id: I46f6600075c0c370e640b807066247237f93c7ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/264300
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Matthew Dempsky
Alexander Rakoczy
Keith Randall
Russ Cox
Ian Lance Taylor
Cherry Zhang
Jason A. Donenfeld
Cuong Manh Le
Robert Griesemer
Lynn Boger
Alberto Donizetti
David Chase
Cholerae Hu
Michael Munday
Branden J Brown