cmp/compile: superfluous indices in slice expressions contribute to the enclosing function's inlining cost

[jub0bs]

Go version

go version go1.25.1 darwin/amd64

Output of go env in your module/workspace:

N/A

What did you do?

I ran

go build -gcflags '-m=2' . 2>&1 | grep 'can inline'

on a package consisting of the following file:

package p

var a, b []int

func NoIndices() {
	b = a[:]
}

func LowIndex() {
	b = a[0:]
}

func HighIndex() {
	b = a[:len(a)]
}

func BothIndices() {
	b = a[0:len(a)]
}

What did you see happen?

Superfluous indices in slice expressions contribute to the enclosing function's inlining cost.

./p.go:5:6: can inline NoIndices with cost 4 as: func() { b = a[:] }
./p.go:9:6: can inline LowIndex with cost 5 as: func() { b = a[0:] }
./p.go:13:6: can inline HighIndex with cost 6 as: func() { b = a[:len(a)] }
./p.go:17:6: can inline BothIndices with cost 7 as: func() { b = a[0:len(a)] }

What did you expect to see?

Superfluous indices in slice expressions do not contribute to the enclosing function's inlining cost:

./p.go:5:6: can inline NoIndices with cost <n> as: func() { b = a[:] }
./p.go:9:6: can inline LowIndex with cost <n> as: func() { b = a[0:] }
./p.go:13:6: can inline HighIndex with cost <n> as: func() { b = a[:len(a)] }
./p.go:17:6: can inline BothIndices with cost <n> as: func() { b = a[0:len(a)] }

See this now abandoned CL, in which dropping a superfluous low index in a slice expression is enough to make path.Base inlineable.

Related: #61502

[TapirLiu]

The current inline cost model is very rough. There are tons of such cases.

b = a will get even smaller inline cost.

Two other examples:

func sum3(s []int) (r int) { // inline cost 19
   for i := 0; i < len(s); i++ {
      r += s[i]
   }
   return
}

func sum4(s []int) (r int) { // inline cost 11
   for i := range s {
      r += s[i]
   }
   return
}

type T struct {
   x int
}

func f() *T { // inline cost 2
   return new(T)
}

func g() *T { // inline cost 3
   return &T{}
}

[gabyhelp]

Related Issues

• cmd/compile: low function inline cost #54407 (closed)
• cmd/compile: functions using ellipsis arguments are not inlined #18361 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[prattmic]

cc @golang/compiler

[fengyoulin]

I think at least we can make a[0:len(a)] have no extra cost over a[:] .

[gopherbot]

Change https://go.dev/cl/701216 mentions this issue: cmd/compile/internal/inline: ignore superfluous slicing