The prove pass will mark some shifts bounded, and then we can use that
information to generate better code on riscv64.
Change-Id: Ia22f43d0598453c9417adac7017db28d7240948b
Reviewed-on: https://go-review.googlesource.com/c/go/+/422616
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The negation does not change the comparison to zero.
Also remove unnecessary x.Uses == 1 condition from equivalent BEQZ/BNEZ rules.
Change-Id: I62dd8e383e42bfe5c46d11bbf78d8e5ff862a1d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/426262
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The result of these operations are already extended.
Change-Id: Ifc8ba362dda7035d8fd0d40046a96f61d3082877
Reviewed-on: https://go-review.googlesource.com/c/go/+/426260
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Removes more than 2000 instructions from the Go binary on linux/risv64.
Change-Id: I6db3e3b1c93f29f00869adcba7c6192bfb90b25c
Reviewed-on: https://go-review.googlesource.com/c/go/+/426259
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A condition check was added to parse.go in CL 405542 to prevent
usage of scaled operands on ppc64. However while trying to improve
the error notification message, an if-condition was left out by
oversight. This CL corrects that.
Change-Id: I8cef3dd194c75343354ffe888b5e639e694badde
Reviewed-on: https://go-review.googlesource.com/c/go/+/426994
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously the first operand of MSR could be $0, which would be
converted to the ZR register. This is prohibited by CL 404316,
this CL restores this instruction format.
Change-Id: I5b5be59e76aa58423a0fb96942d1b2a9de62e311
Reviewed-on: https://go-review.googlesource.com/c/go/+/426198
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
If x+delta cannot overflow/underflow, we can derive:
x+delta < x if delta<0 (this CL included)
x+delta > x if delta>0 (this CL not included due to
a recursive stack overflow)
Remove 95 bounds checks during ./make.bat
Fixes#51622
Change-Id: I60d9bd84c5d7e81bbf808508afd09be596644f09
Reviewed-on: https://go-review.googlesource.com/c/go/+/406175
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Do not intercept integer compares that are used to increment libFuzzer's
8-bit counters. This is unnecessary and has a negative impact on the
fuzzing performance. This fixes#53760.
Change-Id: Id22efac968b18014eedabb6f0762e1456897024e
GitHub-Last-Rev: 52f69fd68c
GitHub-Pull-Request: golang/go#53786
Reviewed-on: https://go-review.googlesource.com/c/go/+/416796
Run-TryBot: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Looks like CL 413361 which added CaseClause.RTypes missed the need
to regenerate this file.
Also CL 413357 added DynamicTypeAssertExpr.SrcRType, same issue.
Change-Id: I45e4d0685cc2f9bdcef1fad2cfc92e7005ef363e
Reviewed-on: https://go-review.googlesource.com/c/go/+/426675
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 327871 changes methodWrapper to always perform inlining after global
escape analysis. However, inlining the method may reveal closures, which
require walking all function bodies to decide whether to capture free
variables by value or by ref.
To fix it, just not doing inline if the method contains any closures.
Fixes#53702
Change-Id: I4b0255b86257cc6fe7e5fafbc545cc5cff9113e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/426334
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Shape-based stenciling in unified IR is done by converting type argument
to its underlying type. So it agressively check that type argument is
not a TFORW. However, for recursive instantiated type argument, it may
still be a TFORW when shapifying happens. Thus the assertion failed,
causing the compiler crashing.
To fix it, just allow fully instantiated type when shapifying.
Fixes#54512Fixes#54722
Change-Id: I527e3fd696388c8a37454e738f0324f0c2ec16cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/426335
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When a base+displacement kind of operand is given in an index-mode
instruction, the assembler does not flag it as an invalid instruction
causing the user to get an incorrect encoding of that instruction
leading to incorrect execution of the program.
Enable assembler to recognize valid and invalid operands used in index
mode instructions by classifying SOREG type into two further types
XOREG (used uniquely in index addressing mode instructions) and SOREG
for instructions working on base+displacement operands.
Also cleaned up usage of obj.Addr.Scale on PPC64.
Change-Id: Ib4d84343ae57477c6c074f44c4c2749496e11b91
Reviewed-on: https://go-review.googlesource.com/c/go/+/405542
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Archana Ravindar <aravind5@in.ibm.com>
When spilling arg to stack or register, if it's a newly created value,
the arg position should be preserved. Otherwise, we may end up using
position information from deadcode lines.
This fixes the minimized test case in #54625 by mdempsky@, and make
building std successfully. However, the inline trees for these tests
still be corrupted:
- fixedbugs/issue53982.go
- typeparam/issue47775.go
- typeparam/issue47775b.go
- typeparam/issue49432.go
We probably still mess up the inline position somewhere else.
Updates #54625
Change-Id: I0d87e26b9ab451b85b6e79787da74a2b79a16209
Reviewed-on: https://go-review.googlesource.com/c/go/+/425785
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 426079 started checking errors from RecentTag.
Unfortunately, we forgot to run "-longtest" SlowBots, and it turns out
to have broken non-short tests for non-git VCS implementations,
because those don't implement the RecentTag method.
Updates #53935.
Change-Id: I5935f2f4b3f684515e99e8bf70a840154c36249f
Reviewed-on: https://go-review.googlesource.com/c/go/+/426495
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The current implementation ignores the error when it tries to get
the recent tag on revisions, which results in incorrect pseudo
version (v0.0.0-) is derived.
Fixes#53935
Change-Id: I153d851eb913fb7e40051e194c92b9ca5bf0e906
GitHub-Last-Rev: 6ba1d90df5
GitHub-Pull-Request: golang/go#54701
Reviewed-on: https://go-review.googlesource.com/c/go/+/426079
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Previously the first operand of FMOVD and FMOVS could be $0, which
would be converted to the ZR register. This is prohibited by CL 404316,
also it broken the encoding of "FMOVD/FMOVS ZR, Rn", this CL restores
this instruction format and fixes the encoding issue.
Fixes#54655.
Fixes#54729.
Change-Id: I9c42cd41296bed7ffd601609bd8ecaa27d11e659
Reviewed-on: https://go-review.googlesource.com/c/go/+/425188
Run-TryBot: Eric Fang <eric.fang@arm.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
A recent change was made for ppc64x to treat ANDCCconst as
a tuple, allowing ANDconst to be removed from the list
of ops. Included in that change were some improvements to the
rules to avoid some extra code, mainly the elimination of a
cmp 0 following an andi. and in some cases the following
isel. While those changes worked for most cases, in a few
cases some extra unnecessary code was generated.
Currently the snippet appears in archive/zip.(*FileHeader).Mode:
ANDCC R4,$1,R5 // andi. r5,r4,1
ANDCC R4,$16,R5 // andi. r5,r4,16
CMPW R5,R0 // cmpw r5,r0
ADDIS $0,$-32768,R5 // lis r5,-32768
OR R5,$511,R5 // ori r5,r5,511
MOVD $438,R6 // li r6,438
ISEL $2,R6,R5,R5 // isel r5,r6,r5,eq
MOVD $-147,R6 // li r6,-147
AND R6,R5,R6 // and r6,r5,r6
ANDCC R4,$1,R4 // andi. r4,r4,1
ISEL $2,R5,R6,R4 // isel r4,r5,r6,eq
The first ANDCC is never used and should not be there.
From the ssa.html file, the scheduler is not putting the Select1
close to the ISEL, which results in the flag being clobbered
before it can be used. By changing the score for a Select0 or Select1
with type Flags, the extra ANDCC does not occur.
Change-Id: I82f4bc7c02afb1c2b1c048dc6995e0b3f9363fb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/424294
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
This removes one of the branches in the atomicCas sequences for
ppc64/ppc64le.
Change-Id: Ibb46fbfdce052889c69e3da298f28caff540d99b
Reviewed-on: https://go-review.googlesource.com/c/go/+/422014
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
This fixes a regression introduced when the "race" mode tag was moved to
the ToolTags field in CL 358539.
Fixes#54468
Change-Id: I107771948a4fe9d743cc13d1c15f324212b08e03
GitHub-Last-Rev: d211e351ef
GitHub-Pull-Request: golang/go#54618
Reviewed-on: https://go-review.googlesource.com/c/go/+/425154
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In typebits.Set we check that the offset is a multiple of the
alignment, which makes perfect sense. But for values like
atomic.Int64, which has 8-byte alignment even on 32-bit platforms
(i.e. the alignment is larger than PtrSize), if it is on stack it
may be under-aligned, as the stack frame is only PtrSize aligned.
Normally we would prevent such values on stack, as the escape
analysis force values with higher alignment to heap. But for a
composite literal assignment like x = AlignedType{...}, the
compiler creates an autotmp for the RHS then copies it to the LHS.
The autotmp is on stack and may be under-aligned. Currently this
may cause an ICE in the typebits.Set check.
This CL makes it align the _offset_ of the autotmp to 8 bytes,
which satisfies the check. Note that this is actually lying: the
actual address at run time may not necessarily be 8-byte
aligned as we only align SP to 4 bytes.
The under-alignment is probably okay. The only purpose for the
autotmp is to copy the value to the LHS, and the copying code we
generate (at least currently) doesn't care the alignment beyond
stack alignment.
Fixes#54638.
Change-Id: I13c16afde2eea017479ff11dfc24092bcb8aba6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/425256
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When inlining function calls, we rewrite the position information on
all of the nodes to keep track of the inlining context. This is
necessary so that at runtime, we can synthesize additional stack
frames so that the inlining is transparent to the user.
However, for function literals, we *don't* want to apply this
rewriting to the underlying function. Because within the function
literal (when it's not itself inlined), the inlining context (if any)
will have already be available at the caller PC instead.
Unified IR was already getting this right in the case of user-written
statements within the function literal, which is what the unit test
for #46234 tested. However, it was still using inline-adjusted
positions for the function declaration and its parameters, which
occasionally end up getting used for generated code (e.g., loading
captured values from the closure record).
I've manually verified that this fixes the hang in
https://go.dev/play/p/avQ0qgRzOgt, and spot-checked the
-d=pctab=pctoinline output for kube-apiserver and kubelet and they
seem better.
However, I'm still working on a more robust test for this (hence
"Updates" not "Fixes") and internal assertions to verify that we're
emitting correct inline trees. In particular, there are still other
cases (even in the non-unified frontend) where we're producing
corrupt (but at least acyclic) inline trees.
Updates #54625.
Change-Id: Iacfd2e1eb06ae8dc299c0679f377461d3d46c15a
Reviewed-on: https://go-review.googlesource.com/c/go/+/425395
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Also:
- fine-tune the implementation for some of the new builtin functions
- make sure the go/types code is an exact as possible copy of the
types2 code
- fix the description and examples for errorcodes.go
Follow-up on CL 423754.
For #53003.
Change-Id: I5c70b74e90c724cf6c842cedc6f8ace26fde372b
Reviewed-on: https://go-review.googlesource.com/c/go/+/425454
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This is a follow up of CL 425101 on RISCV64.
According to RISCV Volume 1, Unprivileged Spec v. 20191213 Chapter 7.1:
If both the high and low bits of the same product are required, then the
recommended code sequence is: MULH[[S]U] rdh, rs1, rs2; MUL rdl, rs1, rs2
(source register specifiers must be in same order and rdh cannot be the
same as rs1 or rs2). Microarchitectures can then fuse these into a single
multiply operation instead of performing two separate multiplies.
So we should not split Muluhilo to separate instructions.
Updates #54607
Change-Id: If47461f3aaaf00e27cd583a9990e144fb8bcdb17
Reviewed-on: https://go-review.googlesource.com/c/go/+/425203
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
These tests invoke the system C compiler and linker.
Skipping them saves a little over half a second of time in short mode.
Updates #54423.
Change-Id: I3e8aa7b53c0c91f7d1e001ec2cd5f7b4954de52d
Reviewed-on: https://go-review.googlesource.com/c/go/+/425206
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Ever since 'go build' was added (in CL 5483069), it has used an atexit
handler to clean up working directories. At some point (prior to CL
95900044), Init was called multiple times per builder, registering
potentially many atexit handlers that execute asynchronously and make
debugging more difficult.
The use of an AtExit handler also makes the Builder (and anything that
uses it) prone to races: the base.AtExit API is not designed for
concurrent use, but cmd/go is becoming increasingly concurrent over
time. The AtExit handler also makes the Builder inappropriate to use
within a unit-test, since the handlers do not run during the test
function and accumulate over time.
This change makes NewBuilder safe for concurrent use by registering
the AtExit handler only once (during BuildInit, which was already not
safe for concurrent use), and using a sync.Map to store the set of
builders that need cleanup in case of an unclean exit. In addition, it
causes the test variant of cmd/go to fail if any Builder instance
leaks from a clean exit, helping to ensure that functions that create
Builders do not leak them indefinitely, especially in tests.
Updates #54423.
Change-Id: Ia227b15b8fa53c33177c71271d756ac0858feebe
Reviewed-on: https://go-review.googlesource.com/c/go/+/425254
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Ever since 'go build' was added (in CL 5483069), it has used an atexit
handler to clean up working directories.
CL 154109 introduced 'cc' command to the script test framework that
called Init on a builder once per invocation. Unfortunately, since
base.AtExit is unsynchronized, the Init added there caused any script
that invokes that command to be unsafe for concurrent use.
This change fixes the race by having the 'cc' command pass in its
working directory instead of allowing the Builder to allocate one.
Following modern Go best practices, it also replaces the in-place Init
method (which is prone to typestate and aliasing bugs) with a
NewBuilder constructor function.
Fixes#54423.
Change-Id: I8fc2127a7d877bb39a1174e398736bb51d03d4d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/425205
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL changes the inliner to process transitive inlining iteratively
after the AST has actually been edited, rather than recursively and
immediately. This is important for handling indirect function calls
correctly, because ir.reassigned walks the function body looking for
reassignments; whereas previously the inlined reassignments might not
have been actually added to the AST yet.
Fixes#54632.
Change-Id: I0dd69813c8a70b965174e0072335bc00afedf286
Reviewed-on: https://go-review.googlesource.com/c/go/+/425257
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Change-Id: Ied16c3be47c863a94d46bd568191057ded4b7d0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/416734
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>