We noticed some hand-translated code that used
nested functions as the translation of asm macros,
and they were too big to inline, and the resulting
performance was underwhelming. Any such closures
really need to be inlined.
Because Gerrit removed votes from a previous patch
set, and because in offline discussion we realized
that this was actually a hard-to-abuse inlining hack,
I decided to turn it up some more, and also add a
"this one goes to 11" joke. The number is utterly
unprincipled, only "simd is supposed to go fast,
and this is a natural use of closures, and we don't
want there to be issues where it doesn't go fast."
The test verifies that the inlining occurs for a
function that exceeds the current inlining threshold.
Inspection of the generated code shows that it has
the desired effect.
Change-Id: I7a8b57c07d6482e6d98cedaf9622c960f956834d
Reviewed-on: https://go-review.googlesource.com/c/go/+/715740
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
