]> Cypherpunks repositories - gostls13.git/commit
[dev.simd] cmd/compile: enhance inlining for closure-of-SIMD
authorDavid Chase <drchase@google.com>
Tue, 28 Oct 2025 17:32:56 +0000 (13:32 -0400)
committerDavid Chase <drchase@google.com>
Wed, 29 Oct 2025 20:46:34 +0000 (13:46 -0700)
commite452f4ac7de6c80e0be69a3c59ae739cfd806917
tree1711a2c90870d4785e71ebfde6091eb31507bdc7
parentca1264ac506900a2978464e4c4d66825133a66e7
[dev.simd] cmd/compile: enhance inlining for closure-of-SIMD

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>
src/cmd/compile/internal/inline/inl.go
test/simd_inline.go [new file with mode: 0644]