Stowage/go
2
0
Fork 0
mirror of https://github.com/golang/go.git synced 2025-12-08 06:10:04 +00:00
Code Issues Projects Releases Packages Wiki Activity
go/src/cmd/compile/internal/ssa/_gen/allocators.go

235 lines
6.8 KiB
Go
Raw Normal View History

all: add missing copyright header Change-Id: Ic61fb181923159e80a86a41582e83ec466ab9bc4 GitHub-Last-Rev: 92469845665fa1f864d257c8bc175201a43b4d43 GitHub-Pull-Request: golang/go#64080 Reviewed-on: https://go-review.googlesource.com/c/go/+/541741 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Jes Cok <xigua67damn@gmail.com>
2023-11-13 08:57:14 +00:00
// Copyright 2022 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
package main
// TODO: should we share backing storage for similarly-shaped types?
// e.g. []*Value and []*Block, or even []int32 and []bool.
import (
"bytes"
"fmt"
"go/format"
"io"
"log"
"os"
)
type allocator struct {
name string // name for alloc/free functions
typ string // the type they return/accept
mak string // code to make a new object (takes power-of-2 size as fmt arg)
capacity string // code to calculate the capacity of an object. Should always report a power of 2.
resize string // code to shrink to sub-power-of-two size (takes size as fmt arg)
clear string // code for clearing object before putting it on the free list
minLog int // log_2 of minimum allocation size
maxLog int // log_2 of maximum allocation size
}
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
type derived struct {
name string // name for alloc/free functions
typ string // the type they return/accept
base string // underlying allocator
}
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
func genAllocators() {
allocators := []allocator{
{
name: "ValueSlice",
typ: "[]*Value",
capacity: "cap(%s)",
mak: "make([]*Value, %s)",
resize: "%s[:%s]",
cmd/compile: use the builtin clear To simplify the code a bit. Change-Id: Ia72f576de59ff161ec389a4992bb635f89783540 GitHub-Last-Rev: eaec8216be964418a085649fcca53a042f28ce1a GitHub-Pull-Request: golang/go#73411 Reviewed-on: https://go-review.googlesource.com/c/go/+/666117 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2025-04-17 07:49:35 +00:00
clear: "clear(%s)",
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
minLog: 5,
maxLog: 32,
},
{
cmd/compile: move limit fact table in prove pass to dense encoding Here begins a pretty major rewrite of the prove pass. The fundamental observation is that although keeping facts about relations between two SSA values could use O(n^2) space, keeping facts about relations between an SSA value and constants needs only O(n) space. We can just keep track of min/max for every SSA value at little cost. Redo the limit table to just keep track of limits for all SSA values. Use just a slice instead of a map. It may use more space (but still just O(n) space), but accesses are a lot faster. And with the cache in the compiler, that space will be reused quickly. This is part of my planning to add lots more constant limits in the prove pass. Change-Id: Ie36819fad5631a8b79c3630fe0e819521796551a Reviewed-on: https://go-review.googlesource.com/c/go/+/599255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-05-18 08:01:27 -07:00
name: "LimitSlice",
typ: "[]limit", // the limit type is basically [4]uint64.
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
capacity: "cap(%s)",
cmd/compile: move limit fact table in prove pass to dense encoding Here begins a pretty major rewrite of the prove pass. The fundamental observation is that although keeping facts about relations between two SSA values could use O(n^2) space, keeping facts about relations between an SSA value and constants needs only O(n) space. We can just keep track of min/max for every SSA value at little cost. Redo the limit table to just keep track of limits for all SSA values. Use just a slice instead of a map. It may use more space (but still just O(n) space), but accesses are a lot faster. And with the cache in the compiler, that space will be reused quickly. This is part of my planning to add lots more constant limits in the prove pass. Change-Id: Ie36819fad5631a8b79c3630fe0e819521796551a Reviewed-on: https://go-review.googlesource.com/c/go/+/599255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-05-18 08:01:27 -07:00
mak: "make([]limit, %s)",
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
resize: "%s[:%s]",
cmd/compile: use the builtin clear To simplify the code a bit. Change-Id: Ia72f576de59ff161ec389a4992bb635f89783540 GitHub-Last-Rev: eaec8216be964418a085649fcca53a042f28ce1a GitHub-Pull-Request: golang/go#73411 Reviewed-on: https://go-review.googlesource.com/c/go/+/666117 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2025-04-17 07:49:35 +00:00
clear: "clear(%s)",
cmd/compile: move limit fact table in prove pass to dense encoding Here begins a pretty major rewrite of the prove pass. The fundamental observation is that although keeping facts about relations between two SSA values could use O(n^2) space, keeping facts about relations between an SSA value and constants needs only O(n) space. We can just keep track of min/max for every SSA value at little cost. Redo the limit table to just keep track of limits for all SSA values. Use just a slice instead of a map. It may use more space (but still just O(n) space), but accesses are a lot faster. And with the cache in the compiler, that space will be reused quickly. This is part of my planning to add lots more constant limits in the prove pass. Change-Id: Ie36819fad5631a8b79c3630fe0e819521796551a Reviewed-on: https://go-review.googlesource.com/c/go/+/599255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-05-18 08:01:27 -07:00
minLog: 3,
maxLog: 30,
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
},
{
name: "SparseSet",
typ: "*sparseSet",
capacity: "%s.cap()",
mak: "newSparseSet(%s)",
resize: "", // larger-sized sparse sets are ok
clear: "%s.clear()",
minLog: 5,
maxLog: 32,
},
{
name: "SparseMap",
typ: "*sparseMap",
capacity: "%s.cap()",
mak: "newSparseMap(%s)",
resize: "", // larger-sized sparse maps are ok
clear: "%s.clear()",
minLog: 5,
maxLog: 32,
},
{
name: "SparseMapPos",
typ: "*sparseMapPos",
capacity: "%s.cap()",
mak: "newSparseMapPos(%s)",
resize: "", // larger-sized sparse maps are ok
clear: "%s.clear()",
minLog: 5,
maxLog: 32,
},
}
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
deriveds := []derived{
{
name: "BlockSlice",
typ: "[]*Block",
base: "ValueSlice",
},
cmd/compile: move limit fact table in prove pass to dense encoding Here begins a pretty major rewrite of the prove pass. The fundamental observation is that although keeping facts about relations between two SSA values could use O(n^2) space, keeping facts about relations between an SSA value and constants needs only O(n) space. We can just keep track of min/max for every SSA value at little cost. Redo the limit table to just keep track of limits for all SSA values. Use just a slice instead of a map. It may use more space (but still just O(n) space), but accesses are a lot faster. And with the cache in the compiler, that space will be reused quickly. This is part of my planning to add lots more constant limits in the prove pass. Change-Id: Ie36819fad5631a8b79c3630fe0e819521796551a Reviewed-on: https://go-review.googlesource.com/c/go/+/599255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-05-18 08:01:27 -07:00
{
name: "Int64",
typ: "[]int64",
base: "LimitSlice",
},
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
{
name: "IntSlice",
typ: "[]int",
cmd/compile: move limit fact table in prove pass to dense encoding Here begins a pretty major rewrite of the prove pass. The fundamental observation is that although keeping facts about relations between two SSA values could use O(n^2) space, keeping facts about relations between an SSA value and constants needs only O(n) space. We can just keep track of min/max for every SSA value at little cost. Redo the limit table to just keep track of limits for all SSA values. Use just a slice instead of a map. It may use more space (but still just O(n) space), but accesses are a lot faster. And with the cache in the compiler, that space will be reused quickly. This is part of my planning to add lots more constant limits in the prove pass. Change-Id: Ie36819fad5631a8b79c3630fe0e819521796551a Reviewed-on: https://go-review.googlesource.com/c/go/+/599255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-05-18 08:01:27 -07:00
base: "LimitSlice",
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
},
{
name: "Int32Slice",
typ: "[]int32",
cmd/compile: move limit fact table in prove pass to dense encoding Here begins a pretty major rewrite of the prove pass. The fundamental observation is that although keeping facts about relations between two SSA values could use O(n^2) space, keeping facts about relations between an SSA value and constants needs only O(n) space. We can just keep track of min/max for every SSA value at little cost. Redo the limit table to just keep track of limits for all SSA values. Use just a slice instead of a map. It may use more space (but still just O(n) space), but accesses are a lot faster. And with the cache in the compiler, that space will be reused quickly. This is part of my planning to add lots more constant limits in the prove pass. Change-Id: Ie36819fad5631a8b79c3630fe0e819521796551a Reviewed-on: https://go-review.googlesource.com/c/go/+/599255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-05-18 08:01:27 -07:00
base: "LimitSlice",
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
},
{
name: "Int8Slice",
typ: "[]int8",
cmd/compile: move limit fact table in prove pass to dense encoding Here begins a pretty major rewrite of the prove pass. The fundamental observation is that although keeping facts about relations between two SSA values could use O(n^2) space, keeping facts about relations between an SSA value and constants needs only O(n) space. We can just keep track of min/max for every SSA value at little cost. Redo the limit table to just keep track of limits for all SSA values. Use just a slice instead of a map. It may use more space (but still just O(n) space), but accesses are a lot faster. And with the cache in the compiler, that space will be reused quickly. This is part of my planning to add lots more constant limits in the prove pass. Change-Id: Ie36819fad5631a8b79c3630fe0e819521796551a Reviewed-on: https://go-review.googlesource.com/c/go/+/599255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-05-18 08:01:27 -07:00
base: "LimitSlice",
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
},
{
name: "BoolSlice",
typ: "[]bool",
cmd/compile: move limit fact table in prove pass to dense encoding Here begins a pretty major rewrite of the prove pass. The fundamental observation is that although keeping facts about relations between two SSA values could use O(n^2) space, keeping facts about relations between an SSA value and constants needs only O(n) space. We can just keep track of min/max for every SSA value at little cost. Redo the limit table to just keep track of limits for all SSA values. Use just a slice instead of a map. It may use more space (but still just O(n) space), but accesses are a lot faster. And with the cache in the compiler, that space will be reused quickly. This is part of my planning to add lots more constant limits in the prove pass. Change-Id: Ie36819fad5631a8b79c3630fe0e819521796551a Reviewed-on: https://go-review.googlesource.com/c/go/+/599255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-05-18 08:01:27 -07:00
base: "LimitSlice",
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
},
{
name: "IDSlice",
typ: "[]ID",
cmd/compile: move limit fact table in prove pass to dense encoding Here begins a pretty major rewrite of the prove pass. The fundamental observation is that although keeping facts about relations between two SSA values could use O(n^2) space, keeping facts about relations between an SSA value and constants needs only O(n) space. We can just keep track of min/max for every SSA value at little cost. Redo the limit table to just keep track of limits for all SSA values. Use just a slice instead of a map. It may use more space (but still just O(n) space), but accesses are a lot faster. And with the cache in the compiler, that space will be reused quickly. This is part of my planning to add lots more constant limits in the prove pass. Change-Id: Ie36819fad5631a8b79c3630fe0e819521796551a Reviewed-on: https://go-review.googlesource.com/c/go/+/599255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-05-18 08:01:27 -07:00
base: "LimitSlice",
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
},
}
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
w := new(bytes.Buffer)
cmd/compile/internal/ssa: generate code via a //go:generate directive The standard way to generate code in a Go package is via //go:generate directives, which are invoked by the developer explicitly running: go generate import/path/of/said/package Switch to using that approach here. This way, developers don't need to learn and remember a custom way that each particular Go package may choose to implement its code generation. It also enables conveniences such as 'go generate -n' to discover how code is generated without running anything (this works on all packages that rely on //go:generate directives), being able to generate multiple packages at once and from any directory, and so on. Change-Id: I0e5b6a1edeff670a8e588befeef0c445613803c7 Reviewed-on: https://go-review.googlesource.com/c/go/+/460135 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2022-05-14 22:45:05 -04:00
fmt.Fprintf(w, "// Code generated from _gen/allocators.go using 'go generate'; DO NOT EDIT.\n")
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
fmt.Fprintln(w)
fmt.Fprintln(w, "package ssa")
fmt.Fprintln(w, "import (")
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
fmt.Fprintln(w, "\"internal/unsafeheader\"")
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
fmt.Fprintln(w, "\"math/bits\"")
fmt.Fprintln(w, "\"sync\"")
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
fmt.Fprintln(w, "\"unsafe\"")
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
fmt.Fprintln(w, ")")
for _, a := range allocators {
genAllocator(w, a)
}
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
for _, d := range deriveds {
for _, base := range allocators {
if base.name == d.base {
genDerived(w, d, base)
break
}
}
}
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
// gofmt result
b := w.Bytes()
var err error
b, err = format.Source(b)
if err != nil {
fmt.Printf("%s\n", w.Bytes())
panic(err)
}
cmd/compile: add up-to-date test for generated files 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> (cherry picked from commit d4c6effaa7b95a2ea149ece4a400c0ace2773839) Reviewed-on: https://go-review.googlesource.com/c/go/+/680975 TryBot-Bypass: David Chase <drchase@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
2025-06-10 14:15:46 -04:00
if err := os.WriteFile(outFile("allocators.go"), b, 0666); err != nil {
cmd/compile: add cache of sizeable objects so they can be reused We kind of have this mechanism already, just normalizing it and using it in a bunch of places. Previously a bunch of places cached slices only for the duration of a single function compilation. Now we can reuse slices across a whole compiler run. Use a sync.Pool of powers-of-two sizes. This lets us use not too much memory, and avoid holding onto memory we're no longer using when a GC happens. There's a few different types we need, so generate the code for it. Generics would be useful here, but we can't use generics in the compiler because of bootstrapping. Change-Id: I6cf37e7b7b2e802882aaa723a0b29770511ccd82 Reviewed-on: https://go-review.googlesource.com/c/go/+/444820 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-10-18 16:07:36 -07:00
log.Fatalf("can't write output: %v\n", err)
}
}
func genAllocator(w io.Writer, a allocator) {
fmt.Fprintf(w, "var poolFree%s [%d]sync.Pool\n", a.name, a.maxLog-a.minLog)
fmt.Fprintf(w, "func (c *Cache) alloc%s(n int) %s {\n", a.name, a.typ)
fmt.Fprintf(w, "var s %s\n", a.typ)
fmt.Fprintf(w, "n2 := n\n")
fmt.Fprintf(w, "if n2 < %d { n2 = %d }\n", 1<<a.minLog, 1<<a.minLog)
fmt.Fprintf(w, "b := bits.Len(uint(n2-1))\n")
fmt.Fprintf(w, "v := poolFree%s[b-%d].Get()\n", a.name, a.minLog)
fmt.Fprintf(w, "if v == nil {\n")
fmt.Fprintf(w, " s = %s\n", fmt.Sprintf(a.mak, "1<<b"))
fmt.Fprintf(w, "} else {\n")
if a.typ[0] == '*' {
fmt.Fprintf(w, "s = v.(%s)\n", a.typ)
} else {
fmt.Fprintf(w, "sp := v.(*%s)\n", a.typ)
fmt.Fprintf(w, "s = *sp\n")
fmt.Fprintf(w, "*sp = nil\n")
fmt.Fprintf(w, "c.hdr%s = append(c.hdr%s, sp)\n", a.name, a.name)
}
fmt.Fprintf(w, "}\n")
if a.resize != "" {
fmt.Fprintf(w, "s = %s\n", fmt.Sprintf(a.resize, "s", "n"))
}
fmt.Fprintf(w, "return s\n")
fmt.Fprintf(w, "}\n")
fmt.Fprintf(w, "func (c *Cache) free%s(s %s) {\n", a.name, a.typ)
fmt.Fprintf(w, "%s\n", fmt.Sprintf(a.clear, "s"))
fmt.Fprintf(w, "b := bits.Len(uint(%s) - 1)\n", fmt.Sprintf(a.capacity, "s"))
if a.typ[0] == '*' {
fmt.Fprintf(w, "poolFree%s[b-%d].Put(s)\n", a.name, a.minLog)
} else {
fmt.Fprintf(w, "var sp *%s\n", a.typ)
fmt.Fprintf(w, "if len(c.hdr%s) == 0 {\n", a.name)
fmt.Fprintf(w, " sp = new(%s)\n", a.typ)
fmt.Fprintf(w, "} else {\n")
fmt.Fprintf(w, " sp = c.hdr%s[len(c.hdr%s)-1]\n", a.name, a.name)
fmt.Fprintf(w, " c.hdr%s[len(c.hdr%s)-1] = nil\n", a.name, a.name)
fmt.Fprintf(w, " c.hdr%s = c.hdr%s[:len(c.hdr%s)-1]\n", a.name, a.name, a.name)
fmt.Fprintf(w, "}\n")
fmt.Fprintf(w, "*sp = s\n")
fmt.Fprintf(w, "poolFree%s[b-%d].Put(sp)\n", a.name, a.minLog)
}
fmt.Fprintf(w, "}\n")
}
cmd/compile: share compiler allocations of similar shapes Use the same allocator for, e.g., []int32 and []int8. Anything with similar base shapes and be coerced into a single allocator, which helps reuse memory more often. There is not much unsafe in the compiler currently. This adds quite a bit, joining cmd/compiler/internal/base/mapfile_mmap.go and some unsafe.Sizeof calls. Change-Id: I95d6d6e47c42b9f0a45f3556f4d7605735e65d99 Reviewed-on: https://go-review.googlesource.com/c/go/+/461084 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org>
2023-01-09 14:29:49 -08:00
func genDerived(w io.Writer, d derived, base allocator) {
fmt.Fprintf(w, "func (c *Cache) alloc%s(n int) %s {\n", d.name, d.typ)
if d.typ[:2] != "[]" || base.typ[:2] != "[]" {
panic(fmt.Sprintf("bad derived types: %s %s", d.typ, base.typ))
}
fmt.Fprintf(w, "var base %s\n", base.typ[2:])
fmt.Fprintf(w, "var derived %s\n", d.typ[2:])
fmt.Fprintf(w, "if unsafe.Sizeof(base)%%unsafe.Sizeof(derived) != 0 { panic(\"bad\") }\n")
fmt.Fprintf(w, "scale := unsafe.Sizeof(base)/unsafe.Sizeof(derived)\n")
fmt.Fprintf(w, "b := c.alloc%s(int((uintptr(n)+scale-1)/scale))\n", base.name)
fmt.Fprintf(w, "s := unsafeheader.Slice {\n")
fmt.Fprintf(w, " Data: unsafe.Pointer(&b[0]),\n")
fmt.Fprintf(w, " Len: n,\n")
fmt.Fprintf(w, " Cap: cap(b)*int(scale),\n")
fmt.Fprintf(w, " }\n")
fmt.Fprintf(w, "return *(*%s)(unsafe.Pointer(&s))\n", d.typ)
fmt.Fprintf(w, "}\n")
fmt.Fprintf(w, "func (c *Cache) free%s(s %s) {\n", d.name, d.typ)
fmt.Fprintf(w, "var base %s\n", base.typ[2:])
fmt.Fprintf(w, "var derived %s\n", d.typ[2:])
fmt.Fprintf(w, "scale := unsafe.Sizeof(base)/unsafe.Sizeof(derived)\n")
fmt.Fprintf(w, "b := unsafeheader.Slice {\n")
fmt.Fprintf(w, " Data: unsafe.Pointer(&s[0]),\n")
fmt.Fprintf(w, " Len: int((uintptr(len(s))+scale-1)/scale),\n")
fmt.Fprintf(w, " Cap: int((uintptr(cap(s))+scale-1)/scale),\n")
fmt.Fprintf(w, " }\n")
fmt.Fprintf(w, "c.free%s(*(*%s)(unsafe.Pointer(&b)))\n", base.name, base.typ)
fmt.Fprintf(w, "}\n")
}
Reference in a new issue Copy permalink