Skip to content

Conversation

@alimpfard
Copy link
Contributor

@alimpfard alimpfard commented Dec 4, 2025

No description provided.

@ladybird-bot
Copy link
Collaborator

Hello!

One or more of the commit messages in this PR do not match the Ladybird code submission policy, please check the lint_commits CI job for more details on which commits were flagged and why.
Please do not close this PR and open another, instead modify your commit message(s) with git commit --amend and force push those changes to update this PR.

@alimpfard alimpfard force-pushed the wasm-fix-lots branch 3 times, most recently from 2cc0c70 to 74fccfb Compare December 4, 2025 02:58
Copy link
Contributor

@Hendiadyoin1 Hendiadyoin1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First glance from my end, will likely take another look at somepoint

Comment on lines 565 to 566
Vector<Value, ArgumentsStaticSize> args = move(arguments);
return configuration.call(interpreter, address, args);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so this is now explicitly not reusing the allocation, and previously was, or am I missing something

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't pass a reference with different inline capacities, I think the move ctor just yoinks the allocation if its big enough anyway.

@@ -105,12 +105,18 @@ constexpr static u32 default_sources_and_destination = (to_underlying(Dispatch::
template<u64 opcode>
struct InstructionHandler { };

struct __attribute__((packed)) ShortenedIPAndAddresses {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you sure the packed is needed?

as it would be quite odd for a simple type to be sized like u32 and still have u64 like alignment

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or does that affect the calling convention
(mainly making sure as packing can be a footgun when accidentally handing out references)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GCC was splitting the struct up and undoing the fix without it, I got annoyed and just slapped packed there to make it stop

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a union would likely also work, but that probably not really nicer

@alimpfard alimpfard force-pushed the wasm-fix-lots branch 11 times, most recently from 5eb10d8 to 40a8d9e Compare December 4, 2025 20:41
@alimpfard
Copy link
Contributor Author

Hmm, looks like this regressed a bunch of benchmarks, drafting until I figure that out.

WasmCoremark    coremark-minimal.wasm       0.797  695.448 ± 692.259 … 698.147  554.250 ± 553.738 … 555.219
WasmMicroBench  call-00-args.wasm           0.809  2.724 ± 2.722 … 2.726        3.367 ± 3.311 … 3.432
WasmMicroBench  call-01-args.wasm           1.065  6.175 ± 6.138 … 6.204        5.797 ± 5.548 … 6.187
WasmMicroBench  call-02-args.wasm           1.081  6.292 ± 6.254 … 6.365        5.819 ± 5.783 … 5.847
WasmMicroBench  call-03-args.wasm           1.054  6.487 ± 6.464 … 6.515        6.157 ± 6.083 … 6.281
WasmMicroBench  call-04-args.wasm           1.046  6.822 ± 6.776 … 6.865        6.524 ± 6.425 … 6.628
WasmMicroBench  call-16-args.wasm           1.069  11.907 ± 11.831 … 12.044     11.141 ± 11.058 … 11.305
WasmMicroBench  call-32-args.wasm           0.94   16.817 ± 16.776 … 16.895     17.882 ± 17.866 … 17.905
WasmRustBench   base64-bench.wasm           0.783  17.661 ± 17.553 … 17.826     22.558 ± 22.488 … 22.671
WasmRustBench   regex-match-bench.wasm      0.778  3.620 ± 3.594 … 3.660        4.653 ± 4.634 … 4.664
WasmRustBench   sha512-bench.wasm           0.498  24.170 ± 24.066 … 24.360     48.580 ± 48.376 … 48.695
WasmCoremark    Total                       0.797  695.448                      554.250
WasmMicroBench  Total                       1.009  57.222                       56.687
WasmRustBench   Total                       0.6    45.451                       75.790
All Suites      Total                       0.778  120.115                      154.354

@alimpfard alimpfard marked this pull request as draft December 5, 2025 14:43
static_assert(
requires { T(value); }, "Conversion operator is missing.");
auto* node = make_node(forward<U>(value));
requires { T(forward<Args>(args)...); }, "Initializer is missing.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here I guess

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also technically an empend now
and kinda weird that the non-try append doesnt have the check relying on the one here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's...true, will "fix".

@@ -105,12 +105,18 @@ constexpr static u32 default_sources_and_destination = (to_underlying(Dispatch::
template<u64 opcode>
struct InstructionHandler { };

struct __attribute__((packed)) ShortenedIPAndAddresses {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a union would likely also work, but that probably not really nicer

@alimpfard
Copy link
Contributor Author

I think I'll make this PR only about the test generation and fixes, the performance stuff will have to stay in the oven a bit more.

We'll be using wasm-tools for Wasm testsuite generation in the next few
commits.
Previously we were reading the arguments in an incorrect order, and
placing the result in the wrong slot.
This also removes the hacky implementation of accumulative relaxed dot,
and just implements it directly as a new operator.
The instruction would be rejected for _much_ smaller values, but we
shouldn't try to calculate (u64)1<<x with x>64.
@alimpfard alimpfard changed the title LibWasm: Switch to wasm-tools for test gen and update to latest spectest (plus random performance fixes) LibWasm: Switch to wasm-tools for test gen and update to latest spectest Dec 7, 2025
@alimpfard alimpfard marked this pull request as ready for review December 7, 2025 14:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants