cmd/compile: relax recursive restriction while inlining

[randall77]

package main

func main() {
	f(100)
}

func f(x int) {
	if x < 0 {
		return
	}
	g(x - 1)
}
func g(x int) {
	h(x - 1)
}
func h(x int) {
	f(x - 1)
}

The compiler refuses to inline anything in this example:

$ go tool compile -m=2 tmp.go
tmp.go:7:6: cannot inline f: recursive
tmp.go:13:6: cannot inline g: recursive
tmp.go:16:6: cannot inline h: recursive
tmp.go:3:6: can inline main as: func() { f(100) }

There's no reason to not inline, e.g., g into f.
As long as we're not inlining a function into itself, it should be ok (and even that might be ok, as long as we don't do it an infinite number of times).

This comes up only with mid-stack inlining. When we only inlined leaves, it was perfectly reasonable to abort on recursion. Now we don't have to.

This came up when looking at runtime.pcdatavalue. I had a CL (CL 157799) which modified it, and the modified version should have inlined. It didn't because of this issue, because pcdatavalue it is part of a reasonably large recursive loop.

[randall77]

@josharian

[josharian]

This might also help with a problem @CAFxX ran into (which also has another possible solution).

[randall77]

Nothing planned for 1.13, punting.

[CAFxX]

I just ran into a similar problem again; also in my case the recursion loop was fairly big and, crucially, it contained non-inlineable functions (both way over budget as well as containing non-inlineable constructs).

In the spirit of @josharian's CL this would require filtering out not just functions marked as noinline, but also any function that effectively has no chances of being inlined.

[gopherbot]

Change https://golang.org/cl/226818 mentions this issue: cmd/compile: allow mid-stack inlining when there is a cycle of recursion

[gopherbot]

Change https://golang.org/cl/227346 mentions this issue: runtime/pprof: clarify recursive inline heuristic