golang/go

cmd/compile: unnecessary bounds check when slicing after using `slices.Grow`

Open

#73,145 opened on 2025年4月3日

GitHub で見る
 (2 comments) (1 reaction) (0 assignees)Go (133,883 stars) (19,008 forks)batch import
BugReportNeedsInvestigationPerformancecompiler/runtimehelp wanted

説明

Go version

go version go1.24.1 linux/amd64

Output of go env in your module/workspace:

-

What did you do?

package pkg

import "slices"

func Foo() {
	var xs []int
	xs = slices.Grow(xs, 4)[:len(xs)+4]
}

What did you see happen?

Slicing after growing inserts a check for the capacity and a conditional call to runtime.panicSliceAcap

What did you expect to see?

The compiler should be able to tell that we just guaranteed that the slice's capacity is at least len(xs)+4 and shouldn't insert another check.

コントリビューターガイド

技術スタック
go
領域
backendperformance
Issue 種別
performance
難度新しい貢献者にとっての実装難度です。1 は非常に小さな変更、5 は専門的な作業です。
4
推定時間経験ある貢献者が調査、実装、テスト、pull request 準備にかけるおおよその時間範囲です。
half day
活動状況Issue が今どれだけ取り組みやすいかを示します。新しい、活発、古い、ブロック中、またはメンテナー入力待ちなどです。
fresh
明確さ期待される変更、受け入れ条件、次の手順がどれだけ明確かを示します。
clear
前提条件
Go compiler internalsSSA prove passbounds check elimination
初心者向け度初回貢献者にどれだけ取り組みやすいかを 1-100 で推定したスコアです。
30
調査方針
Examine the prove pass in cmd/compile/internal/ssa/prove.go to understand how capacity checks are eliminated. Look for existing rules that prove slice capacity after built in functions like append. Implement a new rule that recognizes the pattern 'slices.Grow(s, n)[:len(s)+n]' and ensures the capacity is at least len(s)+n. Check existing linked issues or CLs for similar optimizations.