aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/testdata
diff options
context:
space:
mode:
authorDavid Chase <drchase@google.com>2025-10-28 13:32:56 -0400
committerDavid Chase <drchase@google.com>2025-10-29 13:46:34 -0700
commite452f4ac7de6c80e0be69a3c59ae739cfd806917 (patch)
tree1711a2c90870d4785e71ebfde6091eb31507bdc7 /src/runtime/testdata
parentca1264ac506900a2978464e4c4d66825133a66e7 (diff)
downloadgo-e452f4ac7de6c80e0be69a3c59ae739cfd806917.tar.xz
[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>
Diffstat (limited to 'src/runtime/testdata')
0 files changed, 0 insertions, 0 deletions