cmd/compile: inline harder to optimize closure allocation

[hirochachacha]

I'm not sure but sometimes using closure causes unwanted allocations.

Please see https://go-review.googlesource.com/#/c/27211/ and https://go-review.googlesource.com/#/c/27210/.

I also don't know this is fixable or not, sorry.

[bradfitz]

Note that this is about all the strings.Trim* and bytes.Trim* functions.

It looks like if the compiler could inline the super-trivial single-line makeCutsetFunc, then the escape analysis does work.

This patch makes removes the only allocation from strings.TrimLeft:

diff --git a/src/strings/strings.go b/src/strings/strings.go
index 738c493..7faa447 100644
--- a/src/strings/strings.go
+++ b/src/strings/strings.go
@@ -600,7 +600,7 @@ func TrimLeft(s string, cutset string) string {
        if s == "" || cutset == "" {
                return s
        }
-       return TrimLeftFunc(s, makeCutsetFunc(cutset))
+       return TrimLeftFunc(s, func(r rune) bool { return IndexRune(cutset, r) >= 0 })
 }       

where makeCutsetFunc is just:

func makeCutsetFunc(cutset string) func(rune) bool {
        return func(r rune) bool { return IndexRune(cutset, r) >= 0 }
}

I guess that is too "hairy" to be inlined, but it probably should be.

/cc @dr2chase @randall77 @mdempsky @josharian

[josharian]

I started on inlining closures during the last freeze and got stuck. I'll mail some of the finished preliminary work; it's just waiting for me to get to it. Lots to mail, little time.

[ALTree]

This is #10292 (which also cites Trim performance) and also #15561 I guess?

[hirochachacha]

True. this is exactly dup.