[インデックス 16440] ファイルの概要

このコミットは、Goコンパイラ（cmd/gc）におけるスライス作成の最適化に関するものです。具体的には、make([]T, constant)のように、長さと容量がコンパイル時に既知の定数であり、かつエスケープ解析によってヒープにエスケープしないと判断されたスライスについて、より効率的なコード生成を行うように変更されています。これにより、不要なヒープアロケーションを削減し、パフォーマンスを向上させることが目的です。

コミット

commit 2c4b029b752a5aa8315e56b9563b2052fe8dd3fe
Author: Rémy Oudompheng <oudomphe@phare.normalesup.org>
Date:   Thu May 30 08:32:00 2013 +0200

    cmd/gc: use escape analysis result for make([]T, constant

    Escape analysis already gives that the underlying array
    does not escape but the result was ignored.

    Fixes #5484.

    R=golang-dev, dave, daniel.morsing
    CC=golang-dev
    https://golang.org/cl/9662046

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/2c4b029b752a5aa8315e56b9563b2052fe8dd3fe

元コミット内容

cmd/gc: use escape analysis result for make([]T, constant

このコミットメッセージは、Goコンパイラ（cmd/gc）が、make([]T, constant)形式のスライス作成において、エスケープ解析の結果を利用するように変更されたことを示しています。具体的には、基盤となる配列がエスケープしない（ヒープに割り当てられる必要がない）とエスケープ解析が既に判断しているにもかかわらず、その結果が無視されていた問題を修正し、最適化を適用するものです。

変更の背景

Go言語では、スライスは内部的に配列へのポインタ、長さ、容量を持つ構造体です。make([]T, len, cap)のようにスライスを作成する際、通常は基盤となる配列がヒープに割り当てられます。しかし、Goコンパイラには「エスケープ解析」という最適化手法があり、変数がそのスコープ外に「エスケープ」するかどうかを判断します。もし変数がエスケープしないと判断された場合、その変数はスタックに割り当てることが可能になり、ヒープアロケーションのオーバーヘッドを避けることができます。

このコミット以前は、make([]T, constant)のように、長さと容量がコンパイル時に既知の定数であるスライスを作成する場合でも、エスケープ解析によって基盤となる配列がエスケープしないと判断されていても、その結果が活用されていませんでした。つまり、不要なヒープアロケーションが発生していた可能性があります。

この変更の背景には、Goプログラムのパフォーマンス向上とメモリ使用量の削減という目標があります。特に、小さなスライスが頻繁に作成され、それが関数スコープ内で完結する場合、スタックアロケーションに切り替えることでガベージコレクションの負荷を軽減し、実行速度を向上させることができます。

この変更は、Go Issue #5484 に対応するものです。このIssueでは、make([]byte, 10)のようなコードがヒープアロケーションを引き起こすことが報告されており、エスケープ解析の結果を適切に利用してスタックアロケーションに切り替えるべきであるという議論がなされていました。

前提知識の解説

Go言語のスライス

Go言語のスライスは、配列をラップした動的なビューです。スライスは以下の3つの要素で構成されます。

1. ポインタ: 基盤となる配列の先頭要素へのポインタ。
2. 長さ (length): スライスに含まれる要素の数。
3. 容量 (capacity): 基盤となる配列の、スライスが参照できる最大要素数。

make([]T, length, capacity)関数を使ってスライスを作成すると、指定された長さと容量を持つ基盤配列が作成され、その配列を参照するスライスが返されます。capacityを省略するとlengthと同じ値になります。

エスケープ解析 (Escape Analysis)

エスケープ解析は、コンパイラが行う最適化の一つで、変数がその宣言されたスコープの外に「エスケープ」するかどうかを判断します。

• エスケープする: 変数が関数の戻り値として返されたり、グローバル変数やヒープに割り当てられたデータ構造の一部として参照されたりする場合、その変数はエスケープすると判断されます。エスケープする変数は、関数の実行が終了しても存在し続ける必要があるため、ヒープに割り当てられる必要があります。
• エスケープしない: 変数がその関数スコープ内でのみ使用され、関数の終了とともに不要になる場合、その変数はエスケープしないと判断されます。エスケープしない変数は、スタックに割り当てることができ、ヒープアロケーションのオーバーヘッド（アロケーション、ガベージコレクション）を避けることができます。

エスケープ解析は、Goプログラムのパフォーマンスにとって非常に重要です。ヒープアロケーションを減らすことで、ガベージコレクタの実行頻度を減らし、プログラムの実行速度を向上させることができます。

cmd/gc (Goコンパイラ)

cmd/gcは、Go言語の公式コンパイラです。Goのソースコードを機械語に変換する役割を担っています。コンパイルプロセスには、構文解析、型チェック、中間コード生成、最適化、コード生成など、様々な段階が含まれます。 src/cmd/gc/walk.cは、コンパイラの「ウォーク」フェーズに関連するC言語のソースファイルです。このフェーズでは、抽象構文木（AST）を走査し、型チェック後のノードに対してさらなる変換や最適化を行います。

技術的詳細

このコミットは、Goコンパイラのsrc/cmd/gc/walk.cファイル内のwalkexpr関数、特にOMAKESLICE（スライス作成）のケースに修正を加えています。

変更の核心は、make([]T, nel, max)のようなスライス作成式が処理される際に、以下の条件がすべて満たされる場合に、ヒープアロケーションを伴うmakesliceランタイム関数呼び出しの代わりに、スタックアロケーションとスライス操作に切り替えるというものです。

1. n->esc == EscNone: エスケープ解析の結果、スライスがヒープにエスケープしないと判断された場合。EscNoneは、その変数がエスケープしないことを示すフラグです。
2. smallintconst(l) && smallintconst(r): スライスの長さ（l）と容量（r）が、コンパイル時に既知の小さな整数定数である場合。smallintconstは、与えられたノードが小さな整数定数であるかをチェックする関数です。
3. mpgetfix(r->val.u.xval) < (1ULL<<16) / t->type->width: 容量rが、特定の閾値（65536 / 要素のサイズ）よりも小さい場合。この条件は、スタックに割り当てる配列のサイズが大きくなりすぎないようにするためのものです。1ULL<<16は65536（2の16乗）を意味し、これはスタックに割り当てる配列の最大サイズを制限するためのマジックナンバーと考えられます。t->type->widthは、スライスの要素の型が占めるバイト数です。

これらの条件が満たされた場合、コンパイラは以下の最適化されたコードを生成します。

// var arr [r]T
// n = arr[:l]
t = aindex(r, t->type); // [r]T (容量rの配列型を生成)
var = temp(t);          // その配列型のテンポラリ変数を生成
a = nod(OAS, var, N);   // テンポラリ変数をゼロ初期化する代入ノード (var = nil)
typecheck(&a, Etop);
*init = list(*init, a); // 初期化リストに追加
r = nod(OSLICE, var, nod(OKEY, N, l)); // arr[:l] (テンポラリ配列を基盤とするスライスを作成)
r = conv(r, n->type); // n->typeが名前付き型の場合に型変換
typecheck(&r, Erv);
walkexpr(&r, init);
n = r;

このコードは、[r]Tという固定サイズの配列をスタック上に確保し（temp(t)）、その配列を基盤として[:l]というスライスを作成します。これにより、makesliceランタイム関数を呼び出すことによるヒープアロケーションが回避されます。

上記の条件が満たされない場合（例えば、スライスがエスケープする場合、長さや容量が定数でない場合、または容量が大きすぎる場合）、コンパイラは従来通りmakesliceランタイム関数を呼び出すコードを生成します。

// makeslice(t *Type, nel int64, max int64) (ary []any)
fn = syslook("makeslice", 1);
argtype(fn, t->type);
n = mkcall1(fn, n->type, init,
    typename(n->type),
    conv(l, types[TINT64]),
    conv(r, types[TINT64]));

この変更により、Goコンパイラはエスケープ解析の結果をより効果的に利用し、特定の条件下でのスライス作成におけるヒープアロケーションを削減できるようになりました。

コアとなるコードの変更箇所

src/cmd/gc/walk.cファイルのwalkexpr関数内のcase OMAKESLICE:ブロック。

--- a/src/cmd/gc/walk.c
+++ b/src/cmd/gc/walk.c
@@ -1246,18 +1246,35 @@ walkexpr(Node **np, NodeList **init)
 		goto ret;
 
 	case OMAKESLICE:
-		// makeslice(t *Type, nel int64, max int64) (ary []any)
 		l = n->left;
 		r = n->right;
 		if(r == nil)
 			l = r = safeexpr(l, init);
 		t = n->type;
-		fn = syslook("makeslice", 1);
-		argtype(fn, t->type);			// any-1
-		n = mkcall1(fn, n->type, init,
-			typename(n->type),
-			conv(l, types[TINT64]),
-			conv(r, types[TINT64]));
+		if(n->esc == EscNone
+			&& smallintconst(l) && smallintconst(r)
+			&& mpgetfix(r->val.u.xval) < (1ULL<<16) / t->type->width) {
+			// var arr [r]T
+			// n = arr[:l]
+			t = aindex(r, t->type); // [r]T
+			var = temp(t);
+			a = nod(OAS, var, N); // zero temp
+			typecheck(&a, Etop);
+			*init = list(*init, a);
+			r = nod(OSLICE, var, nod(OKEY, N, l)); // arr[:l]
+			r = conv(r, n->type); // in case n->type is named.
+			typecheck(&r, Erv);
+			walkexpr(&r, init);
+			n = r;
+		} else {
+			// makeslice(t *Type, nel int64, max int64) (ary []any)
+			fn = syslook("makeslice", 1);
+			argtype(fn, t->type);			// any-1
+			n = mkcall1(fn, n->type, init,
+				typename(n->type),
+				conv(l, types[TINT64]),
+				conv(r, types[TINT64]));
+		}
 		goto ret;
 
 	case ORUNESTR:

コアとなるコードの解説

変更は、OMAKESLICE（スライス作成）の処理ロジックに条件分岐を追加しています。

変更前: 変更前は、OMAKESLICEノードが検出されると、常にsyslook("makeslice", 1)を呼び出してmakesliceランタイム関数への呼び出しを生成していました。このランタイム関数は、基盤となる配列をヒープに割り当てます。

変更後: 変更後は、以下の条件をチェックするif文が追加されています。

1. n->esc == EscNone: 現在処理しているスライス作成ノードnが、エスケープ解析によって「エスケープしない」とマークされているかを確認します。
2. smallintconst(l) && smallintconst(r): スライスの長さlと容量rが、コンパイル時に既知の小さな整数定数であるかを確認します。
3. mpgetfix(r->val.u.xval) < (1ULL<<16) / t->type->width: 容量rが、要素の型サイズt->type->widthで割った65536（1ULL<<16）よりも小さいかを確認します。これは、スタックに割り当てる配列のサイズが大きくなりすぎないようにするための上限チェックです。

これらの条件がすべて真である場合、コンパイラは最適化されたパスを実行します。

• t = aindex(r, t->type); // [r]T: 容量rと要素の型t->typeに基づいて、固定サイズの配列型（例: [10]int）を生成します。
• var = temp(t);: 生成された配列型を持つ一時変数（スタックに割り当てられる）を作成します。
• a = nod(OAS, var, N); // zero temp: 一時変数をゼロ初期化する代入ノードを作成します。Goでは、変数はデフォルトでゼロ値に初期化されるため、これは配列の要素をゼロ値で埋めることに相当します。
• *init = list(*init, a);: この初期化ノードを、現在の関数の初期化リストに追加します。
• r = nod(OSLICE, var, nod(OKEY, N, l)); // arr[:l]: 作成した一時配列varを基盤とし、長さlを持つスライスを作成するノードを生成します。OSLICEはスライス操作を表すオペレーションです。
• r = conv(r, n->type); // in case n->type is named.: もし元のスライス型n->typeが名前付き型（例: type MySlice []int）であった場合、型変換を行います。
• typecheck(&r, Erv); walkexpr(&r, init); n = r;: 生成されたスライスノードrの型チェックを行い、さらにwalkexprを再帰的に呼び出して処理を進め、最終的に現在のノードnを最適化されたスライスノードrで置き換えます。

これらの条件のいずれかが偽である場合、コンパイラは従来のパスを実行し、makesliceランタイム関数を呼び出すコードを生成します。これにより、基盤となる配列はヒープに割り当てられます。

この変更により、コンパイラはエスケープ解析の結果をより賢く利用し、ヒープアロケーションを削減することで、Goプログラムの実行効率を向上させています。

関連リンク

• Go Issue #5484: cmd/gc: make([]byte, 10) allocates on heap
• Go CL 9662046: cmd/gc: use escape analysis result for make([]T, constant

参考にした情報源リンク

• Go言語公式ドキュメント: https://go.dev/
• Go言語のエスケープ解析に関する記事 (例: "Go Escape Analysis" で検索)
• Go言語のスライスに関する記事 (例: "Go Slices" で検索)
• Goコンパイラの内部構造に関する資料 (例: "Go compiler internals" で検索)
• GitHubのGoリポジトリ: https://github.com/golang/go

[インデックス 16440] ファイルの概要

このコミットは、Goコンパイラ（cmd/gc）におけるスライス作成の最適化に関するものです。具体的には、make([]T, constant)のように、長さと容量がコンパイル時に既知の定数であり、かつエスケープ解析によってヒープにエスケープしないと判断されたスライスについて、より効率的なコード生成を行うように変更されています。これにより、不要なヒープアロケーションを削減し、パフォーマンスを向上させることが目的です。

コミット

commit 2c4b029b752a5aa8315e56b9563b2052fe8dd3fe
Author: Rémy Oudompheng <oudomphe@phare.normalesup.org>
Date:   Thu May 30 08:32:00 2013 +0200

    cmd/gc: use escape analysis result for make([]T, constant

    Escape analysis already gives that the underlying array
    does not escape but the result was ignored.

    Fixes #5484.

    R=golang-dev, dave, daniel.morsing
    CC=golang-dev
    https://golang.org/cl/9662046

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/2c4b029b752a5aa8315e56b9563b2052fe8dd3fe

元コミット内容

cmd/gc: use escape analysis result for make([]T, constant

このコミットメッセージは、Goコンパイラ（cmd/gc）が、make([]T, constant)形式のスライス作成において、エスケープ解析の結果を利用するように変更されたことを示しています。具体的には、基盤となる配列がエスケープしない（ヒープに割り当てられる必要がない）とエスケープ解析が既に判断しているにもかかわらず、その結果が無視されていた問題を修正し、最適化を適用するものです。

変更の背景

Go言語では、スライスは内部的に配列へのポインタ、長さ、容量を持つ構造体です。make([]T, len, cap)のようにスライスを作成する際、通常は基盤となる配列がヒープに割り当てられます。しかし、Goコンパイラには「エスケープ解析」という最適化手法があり、変数がそのスコープ外に「エスケープ」するかどうかを判断します。もし変数がエスケープしないと判断された場合、その変数はスタックに割り当てることが可能になり、ヒープアロケーションのオーバーヘッドを避けることができます。

このコミット以前は、make([]T, constant)のように、長さと容量がコンパイル時に既知の定数であるスライスを作成する場合でも、エスケープ解析によって基盤となる配列がエスケープしないと判断されていても、その結果が活用されていませんでした。つまり、不要なヒープアロケーションが発生していた可能性があります。

この変更の背景には、Goプログラムのパフォーマンス向上とメモリ使用量の削減という目標があります。特に、小さなスライスが頻繁に作成され、それが関数スコープ内で完結する場合、スタックアロケーションに切り替えることでガベージコレクションの負荷を軽減し、実行速度を向上させることができます。

この変更は、Go Issue #5484 に対応するものです。このIssueでは、make([]byte, 10)のようなコードがヒープアロケーションを引き起こすことが報告されており、エスケープ解析の結果を適切に利用してスタックアロケーションに切り替えるべきであるという議論がなされていました。

前提知識の解説

Go言語のスライス

Go言語のスライスは、配列をラップした動的なビューです。スライスは以下の3つの要素で構成されます。

1. ポインタ: 基盤となる配列の先頭要素へのポインタ。
2. 長さ (length): スライスに含まれる要素の数。
3. 容量 (capacity): 基盤となる配列の、スライスが参照できる最大要素数。

make([]T, length, capacity)関数を使ってスライスを作成すると、指定された長さと容量を持つ基盤配列が作成され、その配列を参照するスライスが返されます。capacityを省略するとlengthと同じ値になります。

エスケープ解析 (Escape Analysis)

エスケープ解析は、コンパイラが行う最適化の一つで、変数がその宣言されたスコープの外に「エスケープ」するかどうかを判断します。

• エスケープする: 変数が関数の戻り値として返されたり、グローバル変数やヒープに割り当てられたデータ構造の一部として参照されたりする場合、その変数はエスケープすると判断されます。エスケープする変数は、関数の実行が終了しても存在し続ける必要があるため、ヒープに割り当てられる必要があります。
• エスケープしない: 変数がその関数スコープ内でのみ使用され、関数の終了とともに不要になる場合、その変数はエスケープしないと判断されます。エスケープしない変数は、スタックに割り当てることができ、ヒープアロケーションのオーバーヘッド（アロケーション、ガベージコレクション）を避けることができます。

エスケープ解析は、Goプログラムのパフォーマンスにとって非常に重要です。ヒープアロケーションを減らすことで、ガベージコレクタの実行頻度を減らし、プログラムの実行速度を向上させることができます。

cmd/gc (Goコンパイラ)

cmd/gcは、Go言語の公式コンパイラです。Goのソースコードを機械語に変換する役割を担っています。コンパイルプロセスには、構文解析、型チェック、中間コード生成、最適化、コード生成など、様々な段階が含まれます。 src/cmd/gc/walk.cは、コンパイラの「ウォーク」フェーズに関連するC言語のソースファイルです。このフェーズでは、抽象構文木（AST）を走査し、型チェック後のノードに対してさらなる変換や最適化を行います。

技術的詳細

このコミットは、Goコンパイラのsrc/cmd/gc/walk.cファイル内のwalkexpr関数、特にOMAKESLICE（スライス作成）のケースに修正を加えています。

変更の核心は、make([]T, nel, max)のようなスライス作成式が処理される際に、以下の条件がすべて満たされる場合に、ヒープアロケーションを伴うmakesliceランタイム関数呼び出しの代わりに、スタックアロケーションとスライス操作に切り替えるというものです。

1. n->esc == EscNone: エスケープ解析の結果、スライスがヒープにエスケープしないと判断された場合。EscNoneは、その変数がエスケープしないことを示すフラグです。
2. smallintconst(l) && smallintconst(r): スライスの長さ（l）と容量（r）が、コンパイル時に既知の小さな整数定数である場合。smallintconstは、与えられたノードが小さな整数定数であるかをチェックする関数です。
3. mpgetfix(r->val.u.xval) < (1ULL<<16) / t->type->width: 容量rが、特定の閾値（65536 / 要素のサイズ）よりも小さい場合。この条件は、スタックに割り当てる配列のサイズが大きくなりすぎないようにするためのものです。1ULL<<16は65536（2の16乗）を意味し、これはスタックに割り当てる配列の最大サイズを制限するためのマジックナンバーと考えられます。t->type->widthは、スライスの要素の型が占めるバイト数です。

これらの条件が満たされた場合、コンパイラは以下の最適化されたコードを生成します。

// var arr [r]T
// n = arr[:l]
t = aindex(r, t->type); // [r]T (容量rの配列型を生成)
var = temp(t);          // その配列型のテンポラリ変数を生成
a = nod(OAS, var, N); // テンポラリ変数をゼロ初期化する代入ノード (var = nil)
typecheck(&a, Etop);
*init = list(*init, a); // 初期化リストに追加
r = nod(OSLICE, var, nod(OKEY, N, l)); // arr[:l] (テンポラリ配列を基盤とするスライスを作成)
r = conv(r, n->type); // in case n->type is named.
typecheck(&r, Erv);
walkexpr(&r, init);
n = r;

このコードは、[r]Tという固定サイズの配列をスタック上に確保し（temp(t)）、その配列を基盤として[:l]というスライスを作成します。これにより、makesliceランタイム関数を呼び出すことによるヒープアロケーションが回避されます。

上記の条件が満たされない場合（例えば、スライスがエスケープする場合、長さや容量が定数でない場合、または容量が大きすぎる場合）、コンパイラは従来通りmakesliceランタイム関数を呼び出すコードを生成します。

// makeslice(t *Type, nel int64, max int64) (ary []any)
fn = syslook("makeslice", 1);
argtype(fn, t->type);
n = mkcall1(fn, n->type, init,
    typename(n->type),
    conv(l, types[TINT64]),
    conv(r, types[TINT64]));

この変更により、Goコンパイラはエスケープ解析の結果をより効果的に利用し、特定の条件下でのスライス作成におけるヒープアロケーションを削減できるようになりました。

コアとなるコードの変更箇所

src/cmd/gc/walk.cファイルのwalkexpr関数内のcase OMAKESLICE:ブロック。

--- a/src/cmd/gc/walk.c
+++ b/src/cmd/gc/walk.c
@@ -1246,18 +1246,35 @@ walkexpr(Node **np, NodeList **init)
 		goto ret;
 
 	case OMAKESLICE:
-		// makeslice(t *Type, nel int64, max int64) (ary []any)
 		l = n->left;
 		r = n->right;
 		if(r == nil)
 			l = r = safeexpr(l, init);
 		t = n->type;
-		fn = syslook("makeslice", 1);
-		argtype(fn, t->type);			// any-1
-		n = mkcall1(fn, n->type, init,
-			typename(n->type),
-			conv(l, types[TINT64]),
-			conv(r, types[TINT64]));
+		if(n->esc == EscNone
+			&& smallintconst(l) && smallintconst(r)
+			&& mpgetfix(r->val.u.xval) < (1ULL<<16) / t->type->width) {
+			// var arr [r]T
+			// n = arr[:l]
+			t = aindex(r, t->type); // [r]T
+			var = temp(t);
+			a = nod(OAS, var, N); // zero temp
+			typecheck(&a, Etop);
+			*init = list(*init, a);
+			r = nod(OSLICE, var, nod(OKEY, N, l)); // arr[:l]
+			r = conv(r, n->type); // in case n->type is named.
+			typecheck(&r, Erv);
+			walkexpr(&r, init);
+			n = r;
+		} else {
+			// makeslice(t *Type, nel int64, max int64) (ary []any)
+			fn = syslook("makeslice", 1);
+			argtype(fn, t->type);			// any-1
+			n = mkcall1(fn, n->type, init,
+				typename(n->type),
+				conv(l, types[TINT64]),
+				conv(r, types[TINT64]));
+		}
 		goto ret;
 
 	case ORUNESTR:

コアとなるコードの解説

変更は、OMAKESLICE（スライス作成）の処理ロジックに条件分岐を追加しています。

変更前: 変更前は、OMAKESLICEノードが検出されると、常にsyslook("makeslice", 1)を呼び出してmakesliceランタイム関数への呼び出しを生成していました。このランタイム関数は、基盤となる配列をヒープに割り当てます。

変更後: 変更後は、以下の条件をチェックするif文が追加されています。

1. n->esc == EscNone: 現在処理しているスライス作成ノードnが、エスケープ解析によって「エスケープしない」とマークされているかを確認します。
2. smallintconst(l) && smallintconst(r): スライスの長さlと容量rが、コンパイル時に既知の小さな整数定数であるかを確認します。
3. mpgetfix(r->val.u.xval) < (1ULL<<16) / t->type->width: 容量rが、要素の型サイズt->type->widthで割った65536（1ULL<<16）よりも小さいかを確認します。これは、スタックに割り当てる配列のサイズが大きくなりすぎないようにするための上限チェックです。

これらの条件がすべて真である場合、コンパイラは最適化されたパスを実行します。

• t = aindex(r, t->type); // [r]T: 容量rと要素の型t->typeに基づいて、固定サイズの配列型（例: [10]int）を生成します。
• var = temp(t);: 生成された配列型を持つ一時変数（スタックに割り当てられる）を作成します。
• a = nod(OAS, var, N); // zero temp: 一時変数をゼロ初期化する代入ノードを作成します。Goでは、変数はデフォルトでゼロ値に初期化されるため、これは配列の要素をゼロ値で埋めることに相当します。
• *init = list(*init, a);: この初期化ノードを、現在の関数の初期化リストに追加します。
• r = nod(OSLICE, var, nod(OKEY, N, l)); // arr[:l]: 作成した一時配列varを基盤とし、長さlを持つスライスを作成するノードを生成します。OSLICEはスライス操作を表すオペレーションです。
• r = conv(r, n->type); // in case n->type is named.: もし元のスライス型n->typeが名前付き型（例: type MySlice []int）であった場合、型変換を行います。
• typecheck(&r, Erv); walkexpr(&r, init); n = r;: 生成されたスライスノードrの型チェックを行い、さらにwalkexprを再帰的に呼び出して処理を進め、最終的に現在のノードnを最適化されたスライスノードrで置き換えます。

これらの条件のいずれかが偽である場合、コンパイラは従来のパスを実行し、makesliceランタイム関数を呼び出すコードを生成します。これにより、基盤となる配列はヒープに割り当てられます。

この変更により、コンパイラはエスケープ解析の結果をより賢く利用し、ヒープアロケーションを削減することで、Goプログラムの実行効率を向上させています。

関連リンク

• Go Issue #5484: cmd/gc: make([]byte, 10) allocates on heap
• Go CL 9662046: cmd/gc: use escape analysis result for make([]T, constant

参考にした情報源リンク

• Go言語公式ドキュメント: https://go.dev/
• Go言語のエスケープ解析に関する記事 (例: "Go Escape Analysis" で検索)
• Go言語のスライスに関する記事 (例: "Go Slices" で検索)
• Goコンパイラの内部構造に関する資料 (例: "Go compiler internals" で検索)
• GitHubのGoリポジトリ: https://github.com/golang/go