`std.Target`: Use `lime1` as wasm baseline model and `mvp` as generic model #22098

alexrp · 2024-11-29T01:45:21Z

See #21818 and commit messages.

(#21818 should remain open after this to track aligning lime1 exactly with the spec when we upgrade to LLVM 20.)

alexrp · 2024-11-30T09:25:06Z

Ok, the memory.copy/memory.fill bug has been fixed. This should be ready for review.

build.zig

andrewrk

Thanks for looking into this.

Related commits:

1c9bb6a
836f9fc

src/arch/wasm/CodeGen.zig

andrewrk · 2025-01-21T06:24:22Z

What do you think about my idea to introduce a CPU feature called bulk_memory_len0_noop which indicates the wasm runtime always allows length zero bulk memory operations and treats them as no-ops? This would at least be used by zig1.wasm since we control the wasm2c implementation, and beyond that would be a small form of protest against the spec.

alexrp · 2025-01-21T06:25:59Z

What do you think about my idea to introduce a CPU feature called bulk_memory_len0 which indicates the wasm runtime always allows length zero bulk memory operations and treats them as no-ops? This would at least be used by zig1.wasm since we control the wasm2c implementation, and beyond that would be a small form of protest against the spec.

Seems reasonable. I'll add that.

…ill. Apparently the WebAssembly spec requires these instructions to trap if the computed memory access could be out of bounds, even if the length is zero. Really a rather bizarre design choice.

As discussed in #21818, generic is a poor baseline model because that model is a moving target in LLVM. Instead, use mvp, which has no features enabled.

…embly. See: WebAssembly/tool-conventions#235 This is not *quite* using the same features as the spec'd lime1 model because LLVM 19 doesn't have the level of feature granularity that we need for that. This will be fixed once we upgrade to LLVM 20. Part of #21818.

alexrp · 2025-01-22T03:16:22Z

Ok, I've implemented a nontrapping_bulk_memory_len0 feature (named thusly to follow nontrapping_fptoint's precedent), and also implemented nontrapping_fptoint support in wasm2c. I believe wasm2c is now fully lime1-ready; only extended_const is disabled for now due to wasm-opt support.

I did a zig1.wasm update followed by a stage3 bootstrap locally as a smoke test.

andrewrk

Looks great, thanks!

This will mainly be used when targeting our wasm2c implementation which has no problem with zero-length bulk memory operations, as a non-standard extension.

This is more verbose, but at least we now get a compile error instead of UB when a new feature is added to std.Target.wasm.Feature but not to link.Wasm.Feature.

andrewrk · 2025-01-23T19:19:42Z

src/link/Wasm.zig


        pub fn fromCpuFeature(feature: std.Target.wasm.Feature) Tag {
-            return @enumFromInt(@intFromEnum(feature));
+            return switch (feature) {


Good move, this looks a lot better. Sorry about the trouble, I should have done this from the beginning.

alexrp requested review from Luukdegram and andrewrk November 29, 2024 01:45

alexrp force-pushed the wasm-generic-baseline branch 2 times, most recently from 9faab7a to b9ecd95 Compare November 29, 2024 05:54

This comment was marked as resolved.

Sign in to view

alexrp force-pushed the wasm-generic-baseline branch from b9ecd95 to abb51dd Compare November 30, 2024 09:22

alexrp commented Nov 30, 2024

View reviewed changes

build.zig Outdated Show resolved Hide resolved

alexrp force-pushed the wasm-generic-baseline branch from abb51dd to 60cc7e1 Compare November 30, 2024 14:57

alexrp mentioned this pull request Dec 13, 2024

use @branchHint in std.Random.float #22221

Merged

alexrp force-pushed the wasm-generic-baseline branch from 60cc7e1 to b157cf5 Compare January 18, 2025 12:09

andrewrk approved these changes Jan 21, 2025

View reviewed changes

src/arch/wasm/CodeGen.zig Outdated Show resolved Hide resolved

src/arch/wasm/CodeGen.zig Outdated Show resolved Hide resolved

alexrp mentioned this pull request Jan 21, 2025

ci: Switch to Wasmtime v29.0.0. #22563

Merged

alexrp added 3 commits January 22, 2025 03:01

wasm: Add a check for zero length around uses of memory.copy/memory.f…

e800ea0

…ill. Apparently the WebAssembly spec requires these instructions to trap if the computed memory access could be out of bounds, even if the length is zero. Really a rather bizarre design choice.

std.Target: Use mvp as the generic CPU model for wasm32/wasm64.

206373c

As discussed in #21818, generic is a poor baseline model because that model is a moving target in LLVM. Instead, use mvp, which has no features enabled.

alexrp force-pushed the wasm-generic-baseline branch from b157cf5 to 5e54390 Compare January 22, 2025 02:04

alexrp requested a review from andrewrk January 22, 2025 03:16

andrewrk approved these changes Jan 22, 2025

View reviewed changes

alexrp enabled auto-merge January 22, 2025 04:28

alexrp disabled auto-merge January 22, 2025 09:40

alexrp added 3 commits January 22, 2025 20:56

wasm: Add a nontrapping_bulk_memory_len0 feature.

ea15029

This will mainly be used when targeting our wasm2c implementation which has no problem with zero-length bulk memory operations, as a non-standard extension.

wasm2c: Implement nontrapping_fptoint support.

35e804b

link.Wasm.Feature: Make fromCpuFeature() and toCpuFeature() less cute.

68c6a88

This is more verbose, but at least we now get a compile error instead of UB when a new feature is added to std.Target.wasm.Feature but not to link.Wasm.Feature.

alexrp force-pushed the wasm-generic-baseline branch from 848c589 to 68c6a88 Compare January 22, 2025 20:21

alexrp enabled auto-merge January 22, 2025 20:23

alexrp merged commit d916954 into ziglang:master Jan 23, 2025
10 checks passed

alexrp deleted the wasm-generic-baseline branch January 23, 2025 18:09

andrewrk reviewed Jan 23, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

`std.Target`: Use `lime1` as wasm baseline model and `mvp` as generic model #22098

`std.Target`: Use `lime1` as wasm baseline model and `mvp` as generic model #22098

Uh oh!

alexrp commented Nov 29, 2024 •

edited

Loading

Uh oh!

This comment was marked as resolved.

This comment was marked as resolved.

alexrp commented Nov 30, 2024

Uh oh!

Uh oh!

andrewrk left a comment

Uh oh!

Uh oh!

Uh oh!

andrewrk commented Jan 21, 2025 •

edited

Loading

Uh oh!

alexrp commented Jan 21, 2025

Uh oh!

alexrp commented Jan 22, 2025

Uh oh!

andrewrk left a comment

Uh oh!

Uh oh!

andrewrk Jan 23, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

std.Target: Use lime1 as wasm baseline model and mvp as generic model #22098

std.Target: Use lime1 as wasm baseline model and mvp as generic model #22098

Uh oh!

Conversation

alexrp commented Nov 29, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

This comment was marked as resolved.

alexrp commented Nov 30, 2024

Uh oh!

Uh oh!

andrewrk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

andrewrk commented Jan 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexrp commented Jan 21, 2025

Uh oh!

alexrp commented Jan 22, 2025

Uh oh!

andrewrk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

andrewrk Jan 23, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

`std.Target`: Use `lime1` as wasm baseline model and `mvp` as generic model #22098

`std.Target`: Use `lime1` as wasm baseline model and `mvp` as generic model #22098

alexrp commented Nov 29, 2024 •

edited

Loading

andrewrk commented Jan 21, 2025 •

edited

Loading