Yes please.

In practice I suspect the easiest way to accomplish immediately this is to do pattern-matching and increase the budget on match.

More broadly speaking it would be nice if we could somehow predict when partial inlining will result in escape analysis changes, and use that as a signal to increase the budget. But I don't know how to do that simply and cheaply.

cc @mdempsky

will result in escape analysis changes

Not just escape analysis changes, but also significant dead code elimination 😃

Yep. One question is about making inlining decisions per-function vs per call-site. The latter can get more expensive more quickly, but is more powerful.

It occurs to me that potential escape analysis changes might be available by comparing the escape analysis of the trampoline function and the called function, when they have the same signature. Plausible, @mdempsky? I guess we have a phase ordering problem, but escape analysis is cheap and high impact, so maybe worth doing twice?

The dead code removal has to be be per-callsite. But if we are doing purely local, brittle AST-based heuristics, like "err != nil", maybe that'd be cheap enough.

cc also @CAFxX for lock inlining

I think this and other cases like #48195 boil down to the question if we want to add a new inline trigger that gets a function and makes analysis like:

• escape with and without inlining
• pattern (e.g. is it just a dispatch function with a switch or an if that only ever triggers one of the cases)
• cost of code blocks covered by branches
  ...

paired with a more tuned cost model of ast nodes and patterns.

Then we could save some extra information like: If this argument is constant at the calling site then inline, if this output is unused then inline. This e.g. should also trigger for using strings.Index to directly call strings.IndexByte when the Index is a constant string of length 1.

Unless there is some near time direction to support feedback driven optimisation as a first class citizen I would say lets go for it if someone can commit todo the work. We should however invest a bit in making the cost and trigger model easy to configure and verify. e.g. have test similar to asm tests that check some code samples are still inlined as wanted. I would not go so far as having a per ARCH cost model yet but I think the current cost model of ast nodes could be improved to assign lesser costs on patterns of comparisons of if statements.

Another case that I would hope will get optimised as a pattern is e.g.:

func LastIndexByte(s []byte, c byte) int {
	return bytealg.LastIndexByte(s, c)
}

where the function is just an internal forward to another package e.g. arch specific asm function that is selected by build tags. Note that the call might have some extra duplicated or cost arguments.