| Age | Commit message (Collapse) | Author |
|---|
|
CL 687815 recently added TestDebugLines_74576.
The pre-existing debug_lines_test.go file generally restricts the
tested architectures and contains multiple warnings that the
testing approach is useful but fragile, such as:
"These files must all be short because this is super-fragile."
Despite that, initially I wanted to see what happened on the
different architectures on the trybots in case it might show something
surprising, and I let TestDebugLines_74576 run on all architectures.
That seemed to initially work, but the test is now failing on a
linux/risc64 builder (#74669), so it is likely more prudent to be
more conservative and restrict the platforms like many of the
other pre-existing tests, which is what this CL now does.
Fixes #74669
Change-Id: I9e5a7d3ee901f58253cf72e03c2239df338479e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/688856
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
The type-checking logic for append has a special case for
append(bytes, s...) where the typeset for s contains string.
However, this case was triggering even when the typeset contained
only []byte, causing the creation of Signature types of the form
func([]byte, Y) []byte, with the variadic flag set, where Y
is the type of Y (e.g. a type parameter constrained to ~[]byte).
This is an illegal combination: a variadic signature's last
parameter must be a slice, or its typeset must contain string.
This caused x/tools/go/ssa to crash.
This CL narrows the special case to only typesets that contain
string, and adds a test for the inferred signature.
(There's little point in testing that a subsequent NewSignatureType
call would succeed, because the inferred type plainly has
no free type parameters.)
Fixes #73871
Change-Id: Id7641104133371dd6b0077f281cdaa9db84cc1c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/688815
Reviewed-by: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
rewriting optimizations
The literal rewriting optimizations to reduce user allocations
that were implemented in CL 649079 and related CLs like CL 684116
could produce .debug_line tables such that the line numbers
sometimes jumped back to a variable's declaration.
This CL adjusts the positions of the IR nodes to avoid this.
For the first test added here in i74576a.go:
11 func main() {
12 a := 1
13 runtime.Breakpoint()
14 sink = a
15 }
Without this fix, the test reports debug lines of 12, 13, 13, 12, 14.
Note it goes backwards from 13 to a second 12.
With this fix, the test reports debug lines of 12, 13, 13, 14
without going backwards.
The test added in i74576b.go creates a slice via make with a
non-constant argument, which similarly shows debug lines going backwards
before this fix but not after. To address the slice make case, we
create a new BasicLit node to then set its position.
There were some related allocation optimizations for struct literals
such as CL 649555 during the Go 1.25 dev cycle, but at least in some
basic test cases, those optimizations did not seem to produce
debug line issues. The struct literal interface conversion test
added in i74576c.go has the same behavior before and after this change.
Finally, running 'go test ./...' in the delve repo root (4a2a6e1aeb)
seems to have many failures with go1.25rc2, but seems to pass with
this CL.
Fixes #74576
Updates #71359
Change-Id: I31faf5fe4bb352fdcd06bdc8606dbdbc4bbd65f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/687815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
closures
Escape analysis examines functions in batches. In some cases, closures
are in the same batch as their parent function, but in other cases,
the closures are in different batches. This can mean the per-batch
ir.ReassignOracle cache is not as effective.
For example, #74615 has 4,000 closures in a single function that
are all in different batches. For that example, these caches
had an ~80% hit rate.
This CL makes the ir.ReassignOracle cache more broadly scoped, instead
of per batch.
This speeds up escape analysis when a function has many closures
that end up in different batches, including this resolves #74615.
For that example, this cache now has a ~100% hit rate.
In addition, in (*batch).rewriteWithLiterals, we also slightly delay
checking the ir.ReassignOracle cache, which is more natural to do now
compared to when rewriteWithLiterals was first merged. This means we can
avoid consulting or populating the cache in more cases. (We also leave
a new type-related TODO there. If we were to also implement that TODO, a
quick test suggests we could independently resolve the specific example
in #74615 even without making the cache more broadly scoped,
though other conceivable examples would not be helped; the scoping of
the cache is the more fundamental improvement.)
If we look at cumulative time spent via pprof for the #74615 example
using this CL, the work of ir.ReassignOracle escape analysis
cache now typically shows zero cpu samples.
This CL passes "go build -toolexec 'toolstash -cmp' -a std cmd".
Fixes #74615
Change-Id: I3c17c527fbb546ffb8a4fa52cd61e41ff3cdb869
Reviewed-on: https://go-review.googlesource.com/c/go/+/688075
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
For #74478
Change-Id: I902e9a92cdacb5ad6dafa9896640f8196ba1d56a
Reviewed-on: https://go-review.googlesource.com/c/go/+/686115
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
|
|
prove.go used to make my editor and precomit checks very unhappy.
Change-Id: I25f7ffa2191480bc1b4f91fa91ccf3e4768045fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/685818
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
The TestStmtLines test has been accessing a nil pointer when it
tries to look up LineEntry.File.Name on a line entry with
EndSequence set to true. The doc for EndSequence specifies that if
EndSequence is set, only it and the Address field are meaningful. Skip
the entries with EndSequence set when building the set of files.
I've reproduced this issue locally.
Probably also fixes #49372, but will leave that for a follow-up CL.
Fixes #74475
Updates #49372
Change-Id: Ic0664f7652b52a0a20239d13fe16454622740821
Reviewed-on: https://go-review.googlesource.com/c/go/+/685835
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
|
|
Several CLs earlier in this stack added optimizations to reduce
user allocations by recognizing and taking advantage of literals,
including CL 649555, CL 649079, and CL 649035.
This CL adds debug hashing of those changes, which enables use of the
bisect tool, such as 'bisect -compile=literalalloc go test -run=Foo'.
This also allows these optimizations to be manually disabled via
'-gcflags=all=-d=literalallochash=n'.
Updates #71359
Change-Id: I854f7742a6efa5b17d914932d61a32b2297f0c88
Reviewed-on: https://go-review.googlesource.com/c/go/+/675415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
when coverage is enabled
CL 649079 and CL 649035 updated escape analysis to rewrite certain
expressions in OMAKE and OCONVIFACE nodes as optimizations to
reduce user allocations.
Part of the change in CL 649079 disabled those optimzations when
coverage instrumentation was enabled under an incorrect possible theory
of how those optimizations might be "expected" to change coverage
results -- in particular, the cover_build_pkg_select.txt testscript
failed with different coverage results. I now realize that the proper
explanation is that my fix in CL 684116 was needed.
Now that CL 684116 is merged, we should no longer disable these
optimizations when coverage is enabled, which is what this CL does.
This has not been reported as a problem to my knowledge, but without
this CL, one could imagine for example a test using testing.AllocsPerRun
might start failing when coverage was enabled if the result relied on
these optimizations.
As expected, if we place this CL just before the necessary fix in
CL 684116, the cover_build_pkg_select.txt testscript fails with a
changed coverage result. If we place this CL just after CL 684116,
the test passes, also as expected.
Updates #71359
Change-Id: Ib5ff00c267acd85dd423c238d177e91a4d881f9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/684777
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
literals
CL 649035 and CL 649079 updated escape analysis to rewrite
certain operands in OMAKE and OCONVIFACE nodes from non-constant
expressions to basic literals that evaluate to the same value.
However, when doing that rewriting, we need to evaluate any
side effects prior to replacing the expression, which is what
this CL now does.
Issue #74379 reported a problem with OCONVIFACE nodes due to CL 649079.
CL 649035 has essentially the same issue with OMAKE nodes. To illustrate
that, we add a test for the OMAKE case in fixedbugs/issue74379b.go,
which fails without this change. To avoid introducing an unnecessary
temporary for OMAKE nodes, we also conditionalize the main work of
CL 649035 on whether the OMAKE operand is already an OLITERAL.
CL 649555 and CL 649078 were related changes that created read-only
global storage for composite literals used in an interface conversion.
This CL adds a test in fixedbugs/issue74379c.go to illustrate
that they do not have the same problem.
Updates #71359
Fixes #74379
Change-Id: I6645575ef34f1fe2b0241a22dc205875d66b7ada
Reviewed-on: https://go-review.googlesource.com/c/go/+/684116
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
Add a test that would have detected the regression in #74303: interface
method fields should have a recorded type.
For #74303
Change-Id: Ide5df51cd71c38809c364bb4f95950163ecefb66
Reviewed-on: https://go-review.googlesource.com/c/go/+/683595
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Findley <rfindley@google.com>
|
|
This reverts commit 4ac729283c807cdbe0f6c7041f21606019b722cf.
Reason for revert: changes semantics of types.Info.TypeOf; introduces new inconsistency around FieldList types.
For #74303
Change-Id: Ib99558c95f1b615fa9a02b028500ed230c8bb185
Reviewed-on: https://go-review.googlesource.com/c/go/+/683297
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
This runs the ssa/_gen generator writing files into
a temporary directory, and then checks that there are
no differences with what is currently in the ssa directory,
and also checks that any file with the "generated from
_gen/..." header was actually generated, and checks that
the headers on the generated file match the expected
header prefix.
Change-Id: Ic8eeb0b06cf6f2e576a013e865b331a12d3a77aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/680615
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
|
|
CL 622236 forgot to check the mask was also a 32 bit rotate mask. Add
a modified version of isPPC64WordRotateMask which valids the mask is
contiguous and fits inside a uint32.
I don't this is possible when merging SRDconst, the first check should
always reject such combines. But, be extra careful and do it there
too.
Fixes #73153
Change-Id: Ie95f74ec5e7d89dc761511126db814f886a7a435
Reviewed-on: https://go-review.googlesource.com/c/go/+/679775
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Jayanth Krishnamurthy <jayanth.krishnamurthy@ibm.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
CL 641955 changes the Unified IR reader to not doing shapify when
reading reshaping expression. However, this condition only matters with
pointer type shaping, which will lose the original type, causes the
reshaping ends up with a completely different type.
This CL relaxes the condition, always allow non-pointer types shaping.
Updates #71184
Fixes #73947
Change-Id: Ib0bafd8932c52d99266f311b6cbfc75c00383f9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/678335
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
|
|
This reverts CL 650455 and CL 655816.
Reason for revert: it causes #73747. Properly fixing it gets into
trickiness with defer/recover, wrapper, and inlining. We're late
in the Go 1.25 release cycle.
Fixes #73747.
Change-Id: Ifb343d522b18fec3fec73a7c886678032ac8e4df
Reviewed-on: https://go-review.googlesource.com/c/go/+/678575
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
|
|
Fixed #73309
Change-Id: Id715b9c71c95c92143a7fdb5a66b24305346dd3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/678415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Fixes #73955
Change-Id: I7cf3ab4c70dc2e2765b54b88ae8cfc77a3073344
Reviewed-on: https://go-review.googlesource.com/c/go/+/678355
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: Ifc3bf896aaaf7c6ce06a01e3dd43780d203638cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/677755
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
|
|
The type definition and object definition sections have nearly the same
structure - help illustrate that through consistent naming.
Change-Id: Ibed374fca4883a293a7fc16b36034e1acb38362a
Reviewed-on: https://go-review.googlesource.com/c/go/+/677378
Auto-Submit: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
SectionObj has to encode the definition information for each object
type, so it will be a bit long.
Change-Id: I9b9514d58a284a4e64020f99fd1b2a92f7752338
Reviewed-on: https://go-review.googlesource.com/c/go/+/677377
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: Ib99d40a546cb095c1b6c2d33e0735f3b5c681539
Reviewed-on: https://go-review.googlesource.com/c/go/+/677237
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: I06b64ea3c1c02b46e242852f8f0b56d77df42161
Reviewed-on: https://go-review.googlesource.com/c/go/+/677236
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
|
|
Since last time the default.pgo profile is collected, there has
been a lot of development in the compiler. It's time to refresh
the compiler's PGO profile.
Profile collected by running the cmd/compile/profile.sh script on
the gotip-linux-amd64_c3h88-perf_vs_release gomote.
Benchmark results on Linux/AMD64:
│ nopgo.txt │ old.txt │ new.txt │
│ sec/op │ sec/op vs base │ sec/op vs base │
Template 110.4m ± 2% 108.4m ± 1% ~ (p=0.121 n=20) 107.8m ± 1% -2.37% (p=0.006 n=20)
Unicode 98.78m ± 0% 95.16m ± 1% -3.67% (p=0.000 n=20) 93.87m ± 1% -4.98% (p=0.000 n=20)
GoTypes 553.8m ± 0% 548.3m ± 0% -0.99% (p=0.000 n=20) 542.1m ± 0% -2.11% (p=0.000 n=20)
Compiler 88.12m ± 1% 83.22m ± 1% -5.56% (p=0.000 n=20) 81.81m ± 1% -7.17% (p=0.000 n=20)
SSA 3.592 ± 1% 3.499 ± 0% -2.58% (p=0.000 n=20) 3.445 ± 0% -4.08% (p=0.000 n=20)
Flate 64.48m ± 1% 64.99m ± 1% ~ (p=0.341 n=20) 63.10m ± 2% -2.15% (p=0.000 n=20)
GoParser 129.8m ± 1% 127.3m ± 1% -1.88% (p=0.004 n=20) 126.2m ± 1% -2.75% (p=0.000 n=20)
Reflect 286.0m ± 1% 282.3m ± 1% -1.30% (p=0.000 n=20) 280.1m ± 1% -2.06% (p=0.000 n=20)
Tar 129.3m ± 1% 128.4m ± 2% ~ (p=0.565 n=20) 126.3m ± 1% -2.32% (p=0.000 n=20)
XML 152.1m ± 1% 148.2m ± 1% -2.55% (p=0.000 n=20) 147.9m ± 1% -2.79% (p=0.000 n=20)
geomean 197.4m 193.4m -2.04% 190.9m -3.29%
On Linux/ARM64:
│ nopgo.txt │ old.txt │ new.txt │
│ sec/op │ sec/op vs base │ sec/op vs base │
Template 80.78m ± 2% 78.78m ± 1% -2.47% (p=0.000 n=20) 78.15m ± 1% -3.25% (p=0.000 n=20)
Unicode 80.57m ± 1% 75.79m ± 1% -5.94% (p=0.000 n=20) 74.85m ± 0% -7.11% (p=0.000 n=20)
GoTypes 426.4m ± 0% 416.1m ± 0% -2.42% (p=0.000 n=20) 411.0m ± 0% -3.62% (p=0.000 n=20)
Compiler 66.54m ± 1% 64.01m ± 1% -3.79% (p=0.000 n=20) 62.86m ± 1% -5.53% (p=0.000 n=20)
SSA 2.905 ± 0% 2.772 ± 0% -4.56% (p=0.000 n=20) 2.759 ± 0% -5.01% (p=0.000 n=20)
Flate 46.68m ± 0% 45.40m ± 1% -2.75% (p=0.000 n=20) 45.20m ± 0% -3.16% (p=0.000 n=20)
GoParser 95.17m ± 1% 93.54m ± 1% -1.71% (p=0.000 n=20) 92.50m ± 0% -2.80% (p=0.000 n=20)
Reflect 212.4m ± 0% 206.6m ± 1% -2.72% (p=0.000 n=20) 205.4m ± 1% -3.31% (p=0.000 n=20)
Tar 95.64m ± 1% 93.19m ± 1% -2.57% (p=0.000 n=20) 92.55m ± 0% -3.23% (p=0.000 n=20)
XML 111.0m ± 0% 108.0m ± 1% -2.67% (p=0.000 n=20) 107.2m ± 1% -3.38% (p=0.000 n=20)
geomean 148.9m 144.2m -3.17% 142.9m -4.05%
For #60234.
Change-Id: I6c4f0609ba578a2848ce6cfcc748dfdda7222182
Reviewed-on: https://go-review.googlesource.com/c/go/+/677375
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
On these platforms, we set up a frame pointer record below
the current stack pointer, so when we're in duffcopy or duffzero,
we get a reasonable traceback. See #73753.
But because this frame pointer record is below SP, it is vulnerable.
Anything that adds a new stack frame to the stack might clobber it.
Which actually happens in #73748 on amd64. I have not yet come across
a repro on arm64, but might as well be safe here.
The only real situation this could happen is when duffzero or duffcopy
is passed a nil pointer. So we can just avoid the problem by doing the
nil check outside duffzero/duffcopy. That way we never add a frame
below duffzero/duffcopy. (Most other ways to get a new frame below the
current one, like async preempt or debugger-generated calls, don't
apply to duffzero/duffcopy because they are runtime functions; we're
not allowed to preempt there.)
Longer term, we should stop putting stuff below SP. #73753 will
include that as part of its remit. But that's not for 1.25, so we'll
do the simple thing for 1.25 for this issue.
Fixes #73748
Change-Id: I913c49ee46dcaee8fb439415a4531f7b59d0f612
Reviewed-on: https://go-review.googlesource.com/c/go/+/676916
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
We make sure to dump to stderr since that's where the panic information
ends up. Long traces get truncated with a "..." in the middle. We pick
an arbitrary limit of 10 positions, but this could be changed.
For #51603
Change-Id: I02326a93181e94e1c48afc05684240540c2c90ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/676815
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
When creating a new *ir.Name or *ir.LinksymOffsetExpr to represent
a composite literal stored in the read-only data section, we should
use the original type of the expression that was found via
ir.ReassignOracle.StaticValue. (This is needed because the StaticValue
method can traverse through OCONVNOP operations to find its final
result.)
Otherwise, the compilation may succeed, but the linker might erroneously
conclude that a type is not used and prune an itab when it should not,
leading to a call at execution-time to runtime.unreachableMethod, which
throws "fatal error: unreachable method called. linker bug?".
The tests exercise both the case of a zero value struct literal that
can be represented by the read-only runtime.zeroVal, which was the case
of the simplified example from #73888, and also modifies that example to
test the non zero value struct literal case.
This CL makes two similar changes for those two cases. We can get either
of the tests we are adding to fail independently if we only make
a single corresponding change.
Fixes #73888
Updates #71359
Change-Id: Ifd91f445cc168ab895cc27f7964a6557d5cc32e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/676517
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Fixes #71184
Change-Id: I22e7ae5203311e86a90502bfe155b0597007887d
Reviewed-on: https://go-review.googlesource.com/c/go/+/641955
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
CL 585399 fixed an initialization loop during IR contruction that
involving alias type, by avoiding publishing alias declarations until
the RHS type expression has been constructed.
There's an assertion to ensure that the alias's type must be the same
during the initialization. However, that assertion is too strict, since
we may construct different instances of the same type, if the type is an
instantination of generic type.
To fix this, we could use types.IdenticalStrict to ensure that these
types matching exactly.
Updates #66873.
Updates #73309.
Change-Id: I2559bed37e21615854333fb1057d7349406e6a1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/668175
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
When transforming for loop variables, the compiler does roughly
following steps:
(1) prebody = {z := z' for z in leaked}
...
(4) init' = (init : s/z/z' for z in leaked)
However, the definition of z is not updated to `z := z'` statement,
causing ReassignOracle incorrectly use the new init statement with z'
instead of z, trigger the ICE.
Fixing this by updating the correct/new definition statement for z
during the prebody initialization.
Fixes #73823
Change-Id: Ice2a6741be7478506c58f4000f591d5582029136
Reviewed-on: https://go-review.googlesource.com/c/go/+/675475
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
unique.Make always copies strings passed into it, so it's safe to not
copy byte slices converted to strings either. Handle this just like map
accesses with string(b) as keys.
This CL only handles unique.Make(string(b)), not nested cases like
unique.Make([2]string{string(b1), string(b2)}); this could be done in a
followup CL but the map lookup code in walk is sufficiently different
than the call handling code that I didn't attempt it. (SSA is much
easier).
Fixes #71926
Change-Id: Ic2f82f2f91963d563b4ddb1282bd49fc40da8b85
Reviewed-on: https://go-review.googlesource.com/c/go/+/672135
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Currently, hash/maphash.Comparable escapes its parameter if it
contains non-string pointers, but does not escape strings or types
that contain strings but no other pointers. This is achieved by a
compiler intrinsic.
unique.Make does something similar: it stores its parameter to a
central map, with strings cloned. So from the escape analysis's
perspective, the non-string pointers are passed through, whereas
string pointers are not. We currently cannot model this type of
type-dependent data flow directly in Go. So we do this with a
compiler intrinsic. In fact, we can unify this and the intrinsic
above.
Tests are from Jake Bailey's CL 671955 (thanks!).
Fixes #73680.
Change-Id: Ia6a78e09dee39f8d9198a16758e4b5322ee2c56a
Reviewed-on: https://go-review.googlesource.com/c/go/+/675156
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jake Bailey <jacob.b.bailey@gmail.com>
|
|
This was the first CL in a series of CLs aimed at reducing
how often interface arguments escape for the print functions in fmt.
This CL makes some small improvements to the escape analysis logging.
Here is a sample snippet of the current -m=2 logs:
./print.go:587:7: parameter p leaks to {heap} with derefs=0:
./print.go:587:7: flow: p = p:
./print.go:587:7: from (*pp).printArg(p, err, 'v') (call parameter) at ./print.go:613:13
./print.go:587:7: flow: p = p:
./print.go:587:7: from (*pp).handleMethods(p, verb) (call parameter) at ./print.go:749:22
[..]
If we attempt to tease apart some reasons why the -m=2 logs can be
challenging to understand for the uninitiated:
- The "flow" lines are very useful, but contain more-or-less abstracted
pseudocode. The "from" lines most often use actual code. When first
looking at the logs, that distinction might not be apparent, which can
result in looking back to the original code to hunt for pseudocode
that doesn't exist there. (The log example shows 'p = p', but there is
no 'p = p' in the original source).
- Escape analysis can be most interesting with inlining, but that can
result in seeing overlapping short variable names (e.g., p, b, v...).
- The directionality of the "flow" lines might not be obvious,
including whether they build top-to-bottom or bottom-to-top.
- The use of '{' and '}' in the -m=2 logs somewhat intersects with Go
literals (e.g., if the log says "{temp}", an initial thought might
be that represents some temp inside of some Go literal).
- And of course, escape analysis itself is subtle.
This CL:
- Adds the function name to the first -m=2 line to provide more context
and reduce how often the reader needs to lookup line numbers.
- Uses the Unicode left arrow '←' rather than '=' on the flow lines
to make it clearer that these lines are abstracted away from the
original Go code and to help the directionality jump out.
In the future, we can consider changing "{heap}", "{temp}",
"{storage for foo}" to something else, but we leave them as is for now.
Two examples with the modifications:
./f1.go:3:9: parameter inptr leaks to outptr for func1 with derefs=0:
./f1.go:3:9: flow: localptr ← inptr:
./f1.go:3:9: from localptr := inptr (assign) at ./f1.go:4:11
./f1.go:3:9: flow: outptr ← localptr:
./f1.go:3:9: from return localptr (return) at ./f1.go:5:2
./b.go:14:20: []byte{...} escapes to heap in byteOrderExample:
./b.go:14:20: flow: b ← &{storage for []byte{...}}:
./b.go:14:20: from []byte{...} (spill) at ./byteorder.go:14:20
./b.go:14:20: from b := []byte{...} (assign) at ./byteorder.go:14:11
./b.go:14:20: flow: <heap> ← b:
./b.go:14:20: from byteOrder.Uint32(b) (call parameter) at ./byteorder.go:15:32
These changes only affect the -m=2 output and leave the -m=1 output
as is.
Updates #8618
Updates #62653
Change-Id: Ic082a371c3d3fa0d8fd8bfbe4d64ec3e1e53c173
Reviewed-on: https://go-review.googlesource.com/c/go/+/524937
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
Fold negation into addition/subtraction and avoid double negation.
file before after Δ %
addr2line 3909260 3909204 -56 -0.001%
asm 6714513 6714505 -8 -0.000%
buildid 3680344 3679504 -840 -0.023%
cgo 6219857 6219521 -336 -0.005%
compile 29527941 29528037 +96 +0.000%
cover 6869451 6868731 -720 -0.010%
dist 4498817 4498769 -48 -0.001%
doc 10483319 10481719 -1600 -0.015%
fix 4356204 4355932 -272 -0.006%
link 9080951 9080383 -568 -0.006%
nm 3899682 3833674 -66008 -1.693%
objdump 6347837 6347605 -232 -0.004%
pack 3103750 3103454 -296 -0.010%
pprof 18849998 18849478 -520 -0.003%
test2json 3619671 3619511 -160 -0.004%
trace 17164007 17161463 -2544 -0.015%
vet 10465861 10465173 -688 -0.007%
total 167058409 166983609 -74800 -0.045%
Change-Id: I1b8cf3939b433e1765682196b8fc1aa07d37f895
Reviewed-on: https://go-review.googlesource.com/c/go/+/673476
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Change-Id: Ie6ff3d2dd62acfad6c1c7827973f1d9381923ca7
Reviewed-on: https://go-review.googlesource.com/c/go/+/675115
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
|
|
zero values
This is a small-ish adjustment to the change earlier in our
stack in CL 649555, which started creating read-only global storage
for a composite literal used in an interface conversion and setting
the interface data pointer to point to that global storage.
In some cases, there are execution-time performance benefits to point
to runtime.zeroVal in particular. In reflect, pointer checks against
the runtime.zeroVal memory address are used to side-step some work,
such as in reflect.Value.Set and reflect.Value.IsZero.
In this CL, we therefore dig up the zeroVal symbol, and we use the
machinery from earlier in our stack to use a pointer to zeroVal for
the interface data pointer if we see examples like:
sink = S{}
or:
s := S{}
sink = s
CL 649076 (also earlier in our stack) added most of the tests
along with debug diagnostics in convert.go to make it easier
to test this change.
We add a benchmark in reflect to show examples of performance benefit.
The left column is our immediately prior CL 649555, and the right is
this CL. (The arrays of structs here do not seem to benefit, which
we attempt to address in our next CL).
goos: linux
goarch: amd64
pkg: reflect
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ cl-649555 │ new │
│ sec/op │ sec/op vs base │
Zero/IsZero/ByteArray/size=16-4 4.176n ± 0% 4.171n ± 0% ~ (p=0.151 n=20)
Zero/IsZero/ByteArray/size=64-4 6.921n ± 0% 3.864n ± 0% -44.16% (p=0.000 n=20)
Zero/IsZero/ByteArray/size=1024-4 21.210n ± 0% 3.878n ± 0% -81.72% (p=0.000 n=20)
Zero/IsZero/BigStruct/size=1024-4 25.505n ± 0% 5.061n ± 0% -80.15% (p=0.000 n=20)
Zero/IsZero/SmallStruct/size=16-4 4.188n ± 0% 4.191n ± 0% ~ (p=0.106 n=20)
Zero/IsZero/SmallStructArray/size=64-4 8.639n ± 0% 8.636n ± 0% ~ (p=0.973 n=20)
Zero/IsZero/SmallStructArray/size=1024-4 79.99n ± 0% 80.06n ± 0% ~ (p=0.213 n=20)
Zero/IsZero/Time/size=24-4 7.232n ± 0% 3.865n ± 0% -46.56% (p=0.000 n=20)
Zero/SetZero/ByteArray/size=16-4 13.47n ± 0% 13.09n ± 0% -2.78% (p=0.000 n=20)
Zero/SetZero/ByteArray/size=64-4 14.14n ± 0% 13.70n ± 0% -3.15% (p=0.000 n=20)
Zero/SetZero/ByteArray/size=1024-4 24.22n ± 0% 20.18n ± 0% -16.68% (p=0.000 n=20)
Zero/SetZero/BigStruct/size=1024-4 24.24n ± 0% 20.18n ± 0% -16.73% (p=0.000 n=20)
Zero/SetZero/SmallStruct/size=16-4 13.45n ± 0% 13.10n ± 0% -2.60% (p=0.000 n=20)
Zero/SetZero/SmallStructArray/size=64-4 14.12n ± 0% 13.69n ± 0% -3.05% (p=0.000 n=20)
Zero/SetZero/SmallStructArray/size=1024-4 24.62n ± 0% 21.61n ± 0% -12.26% (p=0.000 n=20)
Zero/SetZero/Time/size=24-4 13.59n ± 0% 13.40n ± 0% -1.40% (p=0.000 n=20)
geomean 14.06n 10.19n -27.54%
Finally, here are results from the benchmark example from #71323.
Note however that almost all the benefit shown here is from our earlier
CL 649555, which is a more general purpose change and eliminates
the allocation using a different read-only global than this CL.
│ go1.24 │ new │
│ sec/op │ sec/op vs base │
InterfaceAny 112.6000n ± 5% 0.8078n ± 3% -99.28% (p=0.000 n=20)
ReflectValue 11.63n ± 2% 11.59n ± 0% ~ (p=0.330 n=20)
│ go1.24.out │ new.out │
│ B/op │ B/op vs base │
InterfaceAny 224.0 ± 0% 0.0 ± 0% -100.00% (p=0.000 n=20)
ReflectValue 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=20) ¹
│ go1.24.out │ new.out │
│ allocs/op │ allocs/op vs base │
InterfaceAny 1.000 ± 0% 0.000 ± 0% -100.00% (p=0.000 n=20)
ReflectValue 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=20) ¹
Updates #71359
Updates #71323
Change-Id: I64d8cf1a7900f011d2ec59b948388aeda1150676
Reviewed-on: https://go-review.googlesource.com/c/go/+/649078
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
allocating
Today, this interface conversion causes the struct literal
to be heap allocated:
var sink any
func example1() {
sink = S{1, 1}
}
For basic literals like integers that are directly used in
an interface conversion that would otherwise allocate, the compiler
is able to use read-only global storage (see #18704).
This CL extends that to struct and array literals as well by creating
read-only global storage that is able to represent for example S{1, 1},
and then using a pointer to that storage in the interface
when the interface conversion happens.
A more challenging example is:
func example2() {
v := S{1, 1}
sink = v
}
In this case, the struct literal is not directly part of the
interface conversion, but is instead assigned to a local variable.
To still avoid heap allocation in cases like this, in walk we
construct a cache that maps from expressions used in interface
conversions to earlier expressions that can be used to represent the
same value (via ir.ReassignOracle.StaticValue). This is somewhat
analogous to how we avoided heap allocation for basic literals in
CL 649077 earlier in our stack, though here we also need to do a
little more work to create the read-only global.
CL 649076 (also earlier in our stack) added most of the tests
along with debug diagnostics in convert.go to make it easier
to test this change.
See the writeup in #71359 for details.
Fixes #71359
Fixes #71323
Updates #62653
Updates #53465
Updates #8618
Change-Id: I8924f0c69ff738ea33439bd6af7b4066af493b90
Reviewed-on: https://go-review.googlesource.com/c/go/+/649555
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
Fixes #73812
Change-Id: If7a6e103ae9e1442a2cf4a3c6b1270b6a1887196
Reviewed-on: https://go-review.googlesource.com/c/go/+/675175
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
This enables publicationBarrier to be used as an intrinsic on mipsx.
Change-Id: Ic199f34b84b3058bcfab79aac8f2399ff21a97ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/674856
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
This enables publicationBarrier to be used as an intrinsic on mips64x.
Change-Id: I4030ea65086c37ee1dcc1675d0d5d40ef8683851
Reviewed-on: https://go-review.googlesource.com/c/go/+/674855
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
avoid allocs
Currently, the integer value in the following interface conversion gets
heap allocated:
v := 1000
fmt.Println(v)
In contrast, this conversion does not currently cause the integer value
to be heap allocated:
fmt.Println(1000)
The second example is able to avoid heap allocation because of an
optimization in walk (by Josh in #18704 and related issues) that
recognizes a literal is being used. In the first example, that
optimization is currently thwarted by the literal getting assigned
to a local variable prior to use in the interface conversion.
This CL propagates constants to interface conversions like
in the first example to avoid heap allocations, instead using
a read-only global. The net effect is roughly turning the first example
into the second.
One place this comes up in practice currently is with logging or
debug prints. For example, if we have something like:
func conditionalDebugf(format string, args ...interface{}) {
if debugEnabled {
fmt.Fprintf(io.Discard, format, args...)
}
}
Prior to this CL, this integer is heap allocated, even when the
debugEnabled flag is false, and even when the compiler
inlines conditionalDebugf:
v := 1000
conditionalDebugf("hello %d", v)
With this CL, the integer here is no longer heap allocated, even when
the debugEnabled flag is enabled, because the compiler can now see that
it can use a read-only global.
See the writeup in #71359 for more details.
CL 649076 (earlier in our stack) added most of the tests
along with debug diagnostics in convert.go to make it easier
to test this change.
Updates #71359
Updates #62653
Updates #53465
Updates #8618
Change-Id: I19a51e74b36576ebb0b9cf599267cbd2bd847ce4
Reviewed-on: https://go-review.googlesource.com/c/go/+/649079
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
Using the new-ish ir.ReassignOracle is more efficient than calling
ir.StaticValue repeatedly.
This CL now uses an ir.ReassignOracle for the recent
make constant propagation introduced in CL 649035.
We also pull the main change from CL 649035 into a new function,
which we will update later in our stack. We will also use the
ReassignOracles introduced here later in our stack.
(We originally did most of this work in CL 649077, but we abandoned
that in favor of CL 649035).
We could also use an ir.ReassignOracle in the older processing of
ir.OCALLFUNC in (*escape).call, but for now, we just leave that
as a TODO.
Updates #71359
Change-Id: I6e02eeac269bde3a302622b4dfe0c8dc63ec9ffc
Reviewed-on: https://go-review.googlesource.com/c/go/+/673795
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
Reduce the number of go toolchain instructions on loong64 as follows.
file before after Δ %
addr2line 279880 279776 -104 -0.0372%
asm 556638 556410 -228 -0.0410%
buildid 272272 272072 -200 -0.0735%
cgo 481522 481318 -204 -0.0424%
compile 2457788 2457580 -208 -0.0085%
covdata 323384 323280 -104 -0.0322%
cover 518450 518234 -216 -0.0417%
dist 340790 340686 -104 -0.0305%
distpack 282456 282252 -204 -0.0722%
doc 789932 789688 -244 -0.0309%
fix 324332 324228 -104 -0.0321%
link 704622 704390 -232 -0.0329%
nm 277132 277028 -104 -0.0375%
objdump 507862 507758 -104 -0.0205%
pack 221774 221674 -100 -0.0451%
pprof 1469816 1469552 -264 -0.0180%
test2json 254836 254732 -104 -0.0408%
trace 1100002 1099738 -264 -0.0240%
vet 781078 780874 -204 -0.0261%
go 1529116 1528848 -268 -0.0175%
gofmt 318556 318448 -108 -0.0339%
total 13792238 13788566 -3672 -0.0266%
Change-Id: I23fb3ebd41309252c7075e57ea7094e79f8c4fef
Reviewed-on: https://go-review.googlesource.com/c/go/+/674335
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
|
|
In the loong64 instruction set, there is no NORI instruction,
so the immediate value in NORconst need to be stored in register
and then use the three-register NOR instruction.
Change-Id: I5ef697450619317218cb3ef47fc07e238bdc2139
Reviewed-on: https://go-review.googlesource.com/c/go/+/673836
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
many locations
For the package github.com/microsoft/typescript-go/internal/checker,
compilation currently spends most of its time in escape analysis.
Here, we re-order work to be more efficient when analyzing many
locations, and delay visiting some locations to prioritize locations
that might be more likely to reach a terminal point of reaching the
heap and possibly reduce the count of intermediate states for each location.
Action graph reported build times show roughly a 5x improvement for
compilation of the typescript-go/internal/checker package:
go1.24.0: 91.792s
cl-657179-ps1: 17.578s
with timing via:
go build -a -debug-actiongraph=/tmp/actiongraph-cl-657179-ps1 -v github.com/microsoft/typescript-go/internal/checker
There are some additional adjustments to make here, including we can
consider a follow-on CL I have that parallelizes the operations of the
core loop, but this seems to be a nice win as is, and my understanding
is the desire is to merge this as it stands.
Updates #72815
Change-Id: I1753c5354b495b059f68fb97f3103ee7834f9eee
Reviewed-on: https://go-review.googlesource.com/c/go/+/657179
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
This CL implements the TODO in combineStores to allow combining
stores of different sizes, as long as the total size aligns to
2, 4, 8.
Fixes #72832.
Change-Id: I6d1d471335da90d851ad8f3b5a0cf10bdcfa17c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/661855
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: I9b1c9a0499ad3444e8cb3e4be187f9fab816c90c
Reviewed-on: https://go-review.googlesource.com/c/go/+/674159
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Like Sync, Ref[T] is also used to define things like StringRef.
Change-Id: I9e10234504ee4dd03907bb058a6f3ae7e6a287ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/674157
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Mark Freeman <mark@golang.org>
Auto-Submit: Mark Freeman <mark@golang.org>
|
|
Fold negation into addition/subtraction and avoid double negation.
platform: linux/arm64
file before after Δ %
addr2line 3628108 3628116 +8 +0.000%
asm 6208353 6207857 -496 -0.008%
buildid 3460682 3460418 -264 -0.008%
cgo 5572988 5572492 -496 -0.009%
compile 26042159 26041039 -1120 -0.004%
cover 6304328 6303472 -856 -0.014%
dist 4139330 4139098 -232 -0.006%
doc 9429305 9428065 -1240 -0.013%
fix 3997189 3996733 -456 -0.011%
link 8212128 8210280 -1848 -0.023%
nm 3620056 3619696 -360 -0.010%
objdump 5920289 5919233 -1056 -0.018%
pack 2892250 2891778 -472 -0.016%
pprof 17094569 17092745 -1824 -0.011%
test2json 3335825 3335529 -296 -0.009%
trace 15842080 15841456 -624 -0.004%
vet 9472194 9471106 -1088 -0.011%
go 19081541 19081509 -32 -0.000%
total 154253374 154240622 -12752 -0.008%
platform: darwin/arm64
file before after Δ %
compile 27152002 27135490 -16512 -0.061%
link 8372914 8356402 -16512 -0.197%
go 19154802 19154778 -24 -0.000%
total 157734180 157701132 -33048 -0.021%
Change-Id: I15a349bfbaf7333ec3e4a62ae4d06f3f371dfb1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/673715
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Fixes: #72766
Change-Id: I45b521e53c2a11e259dc99e2dfc8e40cac39139a
Reviewed-on: https://go-review.googlesource.com/c/go/+/673575
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
