Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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

このコミットは、Goコンパイラの内部における配列（特に動的配列であるスライス）、文字列、マップの扱いを大幅に整理し、コード生成ロジックをクリーンアップすることを目的としています。具体的には、自動的な間接参照の処理を改善し、不要になったコードパスを削除しています。

コミット

commit ae167bf08f0d40f9c0446b42cd09823d9c50508b
Author: Russ Cox <rsc@golang.org>
Date:   Fri Jan 9 15:21:41 2009 -0800

    clean up automatic indirect, delete some dead code.
    
    R=ken
    OCL=22454
    CL=22457

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

https://github.com/golang/go/commit/ae167bf08f0d40f9c0446b42cd09823d9c50508b

元コミット内容

このコミットの元の内容は、「自動的な間接参照をクリーンアップし、いくつかのデッドコードを削除する」というものです。これは、Goコンパイラが抽象構文木（AST）を処理し、コードを生成する際に、ポインタの自動的なデリファレンス（間接参照の解決）の仕組みを整理し、その結果として不要になった古いコードパスや特殊なケースの処理を削除したことを示唆しています。

変更の背景

Go言語は、その初期段階から、配列とスライスという2つの異なるが関連するデータ構造を持っていました。配列は固定長であり、スライスは動的な長さを持ち、配列の一部を参照するビューとして機能します。コンパイラは、これらのデータ構造を効率的に処理し、適切なコードを生成する必要がありました。

このコミットが行われた2009年1月は、Go言語がまだ一般に公開される前の開発初期段階にあたります。当時のコンパイラ（gcおよび6gなど）は、これらのデータ構造の内部表現や操作に関して、試行錯誤を繰り返していました。特に、ポインタを介した配列やスライスへのアクセス、lenやcapといった組み込み関数のセマンティクス、そして異なる型間の変換（例：固定長配列からスライスへの変換）は、コンパイラにとって複雑な課題でした。

以前のコンパイラ実装では、ポインタを介した配列のインデックス操作のためにOINDEXPTRのような特定のASTノードが存在したり、isptrsarrayやisptrdarrayといった関数でポインタ経由の配列型を区別したりしていました。しかし、このような特殊なケースの扱いは、コードの複雑性を増し、保守性を低下させる可能性がありました。

このコミットの背景には、Go言語の型システムとメモリモデルの設計が固まりつつある中で、コンパイラの内部処理をよりシンプルで一貫性のあるものにするという意図があったと考えられます。特に、ポインタの自動デリファレンスをより統一的に扱うことで、コード生成ロジックを簡素化し、将来的な機能拡張や最適化の基盤を強化することが目的でした。

前提知識の解説

このコミットを理解するためには、以下のGoコンパイラの内部概念とGo言語の基本的なデータ構造に関する知識が必要です。

  1. Goコンパイラの構造:

    • gc (Go Compiler): Go言語のフロントエンドコンパイラ。ソースコードを解析し、抽象構文木（AST）を構築し、型チェックを行い、中間表現（IR）を生成します。
    • 6g (Go Compiler for amd64): gcによって生成されたIRを受け取り、x86-64アーキテクチャ向けの機械語コードを生成するバックエンドコンパイラ。
    • AST (Abstract Syntax Tree): ソースコードの構造を木構造で表現したもの。コンパイラはASTを走査して意味解析やコード生成を行います。
    • Node: ASTの各要素を表す構造体。Nodeには、操作の種類（op）、型情報（type）、子ノード（left, rightなど）が含まれます。
    • Opcode (O-codes): Nodeのopフィールドに格納される、ASTノードの種類を示す定数。例えば、OINDEXは配列やマップのインデックス操作、OINDは間接参照（ポインタのデリファレンス）、OLENはlen組み込み関数を表します。
    • Type: Go言語の型システムにおける型情報を表す構造体。etypeフィールドには基本型（TINT, TARRAY, TMAPなど）が格納されます。

  2. Go言語のデータ構造:

    • 配列 (Array): [N]Tのように宣言される固定長のシーケンス。コンパイル時にサイズが決定されます。
    • スライス (Slice): []Tのように宣言される動的なシーケンス。内部的には、要素へのポインタ、長さ（len）、容量（cap）の3つのフィールドを持つ構造体として表現されます。スライスは配列の一部を参照する「ビュー」として機能します。
    • 文字列 (String): 読み取り専用のバイトスライスとして実装されます。内部的には、バイト列へのポインタと長さの2つのフィールドを持ちます。
    • マップ (Map): キーと値のペアを格納するハッシュテーブル。内部的には、ハッシュテーブルのデータ構造へのポインタとして表現されます。

  3. ポインタと間接参照:

    • Go言語では、変数のアドレスを指すポインタを使用できます。ポインタが指す値にアクセスすることを「間接参照（dereference）」と呼びます。
    • このコミットの文脈では、「自動的な間接参照」とは、コンパイラが特定の状況下で、明示的なポインタデリファレンス演算子（*）がなくても、ポインタが指す値にアクセスするためのコードを自動的に生成することを指します。例えば、pが配列へのポインタである場合、p[i]という式は、コンパイラによって自動的に(*p)[i]のように解釈され、適切なコードが生成される必要があります。

技術的詳細

このコミットの核心は、GoコンパイラがASTを走査し、コードを生成する際の型システムとポインタデリファレンス処理の統一にあります。

  1. OINDEXPTRの廃止とimplicitstarの導入:

    • 以前のコンパイラでは、ポインタを介した配列のインデックス操作（例: (*arrPtr)[i]）を表現するためにOINDEXPTRというASTノードが存在していました。これは、ポインタのデリファレンスとインデックス操作を結合した特殊なノードでした。
    • このコミットでは、OINDEXPTRが完全に削除されました。代わりに、walk.cにimplicitstarという新しいヘルパー関数が導入されました。
    • implicitstar関数は、ASTノードがポインタ型であり、そのポインタがマップ、文字列、または配列（スライスを含む）を指している場合に、そのノードの親としてOIND（間接参照）ノードを挿入します。これにより、ポインタのデリファレンスがAST上で明示的なOINDノードとして表現されるようになります。
    • この変更により、OINDEXノードは、ポインタのデリファレンスを意識することなく、純粋なインデックス操作のみを表現するようになり、コンパイラのロジックが大幅に簡素化されました。

  2. 配列/スライス型判定関数の統一:

    • 以前は、isptrsarray（ポインタが指す固定長配列）、isptrdarray（ポインタが指す動的配列/スライス）、issarray（固定長配列）、isdarray（動的配列/スライス）といった複数の関数で配列の種類を判定していました。
    • このコミットでは、これらの関数が削除され、より明確なisfixedarray（固定長配列）とisslice（スライス）の2つの関数に置き換えられました。
    • この統一により、コンパイラが配列やスライスを扱う際の型判定ロジックがシンプルになり、混乱が少なくなりました。

  3. lenおよびcap組み込み関数の処理の簡素化:

    • cgen.cでは、OLENおよびOCAPオペレーションのコード生成ロジックが変更されました。以前は、文字列、マップ、ポインタが指す動的配列、動的配列といった複数のケースで個別に処理されていましたが、isslice関数の導入により、スライスに対するlen/capの処理が統一されました。
    • 特に、文字列とマップのlenは、そのデータ構造の先頭32ビットワードに長さが格納されているという共通の特性を利用して、より簡潔に処理されるようになりました。

  4. 型変換ロジックの改善:

    • walk.cの型変換ロジック（特に配列とスライスの間）が、新しいisfixedarrayとisslice関数を使用して更新されました。これにより、固定長配列からスライスへ、またはその逆の変換がより正確かつ簡潔に処理されるようになりました。
    • 文字列への変換ロジックも、bytearraysz関数の削除と、TARRAYかつTUINT8型であるかどうかの直接的なチェックに置き換えられました。

  5. デッドコードの削除:

    • OINDEXPTRの廃止と型処理の統一により、関連する多くのデッドコードパスがcgen.c、gsubr.c、subr.c、walk.cから削除されました。これにより、コンパイラのコードベースがスリム化され、理解しやすくなりました。

これらの変更は、Goコンパイラの内部設計における重要な進化を示しており、型システムの一貫性を高め、コード生成の効率と正確性を向上させることに貢献しています。特にimplicitstarの導入は、Go言語のポインタデリファレンスのセマンティクスをコンパイラ内部でより明確に表現するための基盤を築きました。

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

このコミットで変更された主要なファイルと、その中でのコアとなる変更箇所は以下の通りです。

  • src/cmd/6g/cgen.c:
    • cgen関数内のOIND、ODOT、OINDEX、ODOTPTRケースからOINDEXPTRの処理が削除。
    • OLENおよびOCAPの処理において、isptrdarrayやisdarrayの代わりにissliceを使用するように変更。
    • 動的配列から固定長配列への変換、固定長配列から動的配列への変換に関する特殊なコードパスが削除。
  • src/cmd/6g/gsubr.c:
    • sudoaddable関数からOINDEXPTRケースが削除。
  • src/cmd/gc/go.h:
    • enumからOINDEXPTRが削除。
    • isptrsarray, isptrdarray, issarray, isdarray, bytearraysz関数の宣言が削除。
    • isfixedarray, isslice関数の宣言が追加。
  • src/cmd/gc/subr.c:
    • opnames配列からOINDEXPTRのエントリが削除。
    • isptrsarray, isptrdarray, issarray, isdarray, bytearraysz関数の実装が削除。
    • isfixedarray, isslice関数の実装が追加。
  • src/cmd/gc/walk.c:
    • implicitstar関数の新規追加: ポインタが指すマップ、文字列、配列に対してOINDノードを挿入するロジック。
    • walktype関数内のOIND、ODOT、OINDEX、OSLICE、ORANGEなどのケースで、implicitstarが呼び出されるように変更。
    • OINDEXおよびOSLICEの処理からOINDEXPTR関連のロジックが削除。
    • 文字列への変換ロジックでbytearrayszの代わりにistype(l->type->type, TUINT8)を使用するように変更。
    • 配列/スライスの型変換ロジックでissarray/isdarrayの代わりにisfixedarray/issliceを使用するように変更。

コアとなるコードの解説

このコミットの最も重要な変更は、src/cmd/gc/walk.cに導入されたimplicitstar関数と、それに伴うOINDEXPTRの削除です。

implicitstar関数の導入:

void
implicitstar(Node **nn)
{
	Type *t;
	Node *n;

	// insert implicit * if needed
	n = *nn;
	t = n->type;
	if(t == T || !isptr[t->etype])
		return;
	t = t->type;
	if(t == T)
		return;
	switch(t->etype) {
	case TMAP:
	case TSTRING:
	case TARRAY:
		break;
	default:
		return;
	}
	n = nod(OIND, n, N);
	walktype(n, Elv);
	*nn = n;
}

この関数は、引数として渡されたNode（*nn）がポインタ型であり、そのポインタがマップ、文字列、または配列（スライスを含む）を指している場合に、そのノードをデリファレンスするOINDノードをASTに挿入します。これにより、例えばpが*[]int型である場合にp[0]という式があったとすると、walktypeの処理中にimplicitstarが呼び出され、pノードがOIND(p)ノードに置き換えられ、結果的にOINDEX(OIND(p), 0)のようなASTが構築されます。これは、Go言語がポインタを介した配列、スライス、マップ、文字列へのアクセスを自動的にデリファレンスするセマンティクスを、コンパイラのASTレベルで明示的に表現するための重要なステップです。

OINDEXPTRの削除:

以前は、ポインタが指す配列へのインデックス操作はOINDEXPTRという特別なASTノードで処理されていました。しかし、implicitstarが導入され、ポインタのデリファレンスがOINDノードとして統一的に扱われるようになったため、OINDEXPTRは不要になりました。これにより、コンパイラのASTノードの種類が減り、インデックス操作のロジックがOINDEXノードに集約され、コードの複雑性が軽減されました。

型判定関数の変更:

src/cmd/gc/subr.cでは、配列/スライスの型を判定する関数が以下のように変更されました。

// 削除された関数
// isptrsarray, isptrdarray, issarray, isdarray

// 新しく追加された関数
int
isfixedarray(Type *t)
{
	return t != T && t->etype == TARRAY && t->bound >= 0;
}

int
isslice(Type *t)
{
	return t != T && t->etype == TARRAY && t->bound < 0;
}

isfixedarrayは固定長配列（t->bound >= 0）を、issliceはスライス（t->bound < 0、Goコンパイラ内部ではスライスもTARRAY型で表現され、boundが負の値で動的であることを示す）を判定します。これにより、コンパイラ全体で配列とスライスの区別がより明確かつ一貫して行われるようになりました。

これらの変更は、Goコンパイラの内部構造をよりシンプルで堅牢なものにし、Go言語のセマンティクスをより正確に反映するための重要なリファクタリングです。

関連リンク

  • Go言語の公式ドキュメント: https://go.dev/
  • Go言語のソースコード（GitHub）: https://github.com/golang/go
  • Go言語のコンパイラに関する初期の議論（Go開発者メーリングリストなど）: 2009年頃のアーカイブを検索すると、当時の設計思想や課題に関する情報が見つかる可能性があります。

参考にした情報源リンク

  • Go言語のソースコード（特にsrc/cmd/gcとsrc/cmd/6gディレクトリ）
  • Go言語の初期の設計ドキュメントやメーリングリストのアーカイブ（一般公開前の情報のため、特定のURLは提供できませんが、Goの歴史に関する資料に言及がある場合があります）
  • Go言語のコンパイラに関する一般的な知識（AST、型システム、コード生成の概念）