fix(deps): bump the all group with 1 update

[dependabot[bot]]

Bumps the all group with 1 update: github.com/tetratelabs/wazero.

Updates github.com/tetratelabs/wazero from 1.5.0 to 1.6.0

Release notes

Sourced from github.com/tetratelabs/wazero's releases.

v1.6.0

Hey, gophers! Do you know what time it is? It is that time of the year again! That time when we all gather together to share our time with friends and family to celebrate ANOTHER AWESOME WAZERO RELEASE!

Notably, this release includes the first public experimental release of the long-awaited, highly-requested multi-pass optimizing compiler! Keep reading for more details!

A huge thanks to all the contributors, old and new, and always remember that all the developers hang out at the [Gophers Slack][gophers] in the #wazero channel; and if you haven’t already you can star our repo. You know, Santa is making a list, and checking it twice.

It’s been a while since v1.5.0, but we promise v1.6.0 was worth the wait! Fun facts about v1.6.0:

• This is the best release since the last one.
• This release is 100% richer in holiday cheer. ❄️🎄
• Mulled wine is a fantastic developer productivity boost.

The Optimizing Compiler

Jokes aside, we have a lot to cheer about! The lion share of this release is obviously our brand new optimizing compiler (codename “wazevo”) now available as an experimental feature for arm64 (#1496)!

@​mathetake led the design and implementation. Work started this summer, and it has evolved in a few iterations over the last months. Initial focus has been on general abstract infrastructure and support to the arm64 instruction set as our first compilation target. @​evacchi contributed to the arm64 backend with special focus on the SIMD instructions, and @​achille-roussel helped improve the initial register allocator (this was then further evolved and eventually overhauled again by @​mathetake). @​ncruces contributed with suggestions and testing.

We held off a few releases to polish this new compiler and gain more confidence in the implementation. In this first public release, the optimizing compiler is only available for arm64. The journey to supporting amd64 is set to begin soon with @​evacchi leading the effort.

The new compiler has been, as usual, extensively tested against the Wasm spec, our own unit tests, and against the standard libraries of TinyGo, Go and Zig; and of course it has also been hardened through hours-long fuzzing.

You can enable the optimizing compiler by replacing wazero.NewRuntimeConfigCompiler() or wazero.NewRuntimeConfig() with the new experimental API as follows:

-    c := wazero.NewRuntimeConfigCompiler()
+       c := opt.NewRuntimeConfigOptimizingCompiler()
-       c := wazero.NewRuntimeConfig()
+       c := opt.NewRuntimeConfigOptimizingCompiler()

The CLI is now also exposing an experimental flag -optimizing-compiler:

wazero run -optimizing-compiler myapp.wasm

The optimizing compiler is an experimental feature so we welcome your input. It is also a work in progress: we implemented only a few optimization passes, guiding our choices through testing and benchmarking.

It is worth noting that WebAssembly is an interesting beast: since it is a compilation target, most compilers generate pre-optimized output; therefore, some traditional optimization passes may surprisingly only add build-time overhead and produce no observable improvement. However, our work there is far from being done: more optimization passes can be added; we invite you to do your experiments and bring your own suggestions. For instance, among others, we currently implement forms of dead-code elimination, and bounds-checking eliminations.

In your experiments, you should also expect the CompileModule phase to take a while longer than the old compiler: the difference may be noticeable with large modules; but you can still cache the result, so you can pay this cost only once. The good news is that, in our tests, the run-time should always visibly improve. Interestingly enough, there are also some cases where both compile-time and run-time have improved: this might be the case when the input module is not pre-optimized, and the dead-code elimination procedures kick in.

For instance, the Zig standard library is about 2x quicker to compile and 4x faster to run than the old compiler. However, a pre-optimized test binary (e.g. pre-processed [using Binaryen’s wasm-opt][wasm-opt]) will be much faster to build on the old compiler, but the new compiler will still produce 2x faster code. This is fully expected because the old compiler does a straightforward translation from input Wasm to native code: therefore, processing time tends to be low; but if the input is large, the generated output will be large. The new compiler is smarter, in that it is able to drop all the irrelevant code sections; in fact, processing time is about the same on both an optimized and unoptimized binary.

The bottom line is: if you control the Wasm binary, run it through [wasm-opt][wasm-opt] and compare the result for your workload!

Deprecations

... (truncated)

Commits

• 2762404 wazevo(frontend): faster non-imported global access (#1889)
• 68729c0 Correctly exit Stdlib tests on failure (#1888)
• 866d555 wazevo(arm64): optimize out unnecessary UExtend (#1886)
• cd143e8 Makes Std lib tests benchstat compatible (#1887)
• 6fdb893 Fixes std lib cases actually benchmarkable (#1885)
• 8c71d4d Flattens std lib test cases (#1884)
• 823d573 bench: add stdlib benchmark old vs new compiler (#1878)
• fa2b2fc wazevo(frontend): simple bounds check elimination on mem access (#1883)
• d26cbad wazevo(arm64): adds missing PerfMapEnabled branch (#1882)
• 1a067a5 wazevo(arm64): lower constant bitwise ops with bitmask immeidates (#1881)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore ` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore ` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore ` will remove the ignore condition of the specified dependency and ignore conditions