Stream: git-wasmtime

Topic: wasmtime / PR #9896 pulley: Make canonicalize-nan.wast pass


view this post on Zulip Wasmtime GitHub notifications bot (Dec 23 2024 at 14:30):

eagr opened PR #9896 from eagr:canon-nan to bytecodealliance:main:

Helps #9783

view this post on Zulip Wasmtime GitHub notifications bot (Dec 23 2024 at 14:30):

eagr requested cfallin for a review on PR #9896.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 23 2024 at 14:30):

eagr requested wasmtime-compiler-reviewers for a review on PR #9896.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 23 2024 at 14:30):

eagr requested wasmtime-default-reviewers for a review on PR #9896.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 23 2024 at 14:32):

eagr requested wasmtime-core-reviewers for a review on PR #9896.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 23 2024 at 14:32):

eagr requested pchickey for a review on PR #9896.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 23 2024 at 14:32):

eagr updated PR #9896.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 23 2024 at 14:52):

eagr commented on PR #9896:

cargo run --features pulley -- wast --target pulley64 ./tests/misc_testsuite/simd/canonicalize-nan.wast -W nan-canonicalization

Seems passing. Is it how the test supposed to run?

About the fn naming, I'm just kinda going along with veq32x4 and friends. If you'd prefer, say, vlef32x4 over vlteqf32x4, or vueqf64x2 over vunoeqf64x2, I'm happy to change them.

And I haven't implemented all the float condcodes, just enough to get the tests pass. I did skim through the docs, but I don't believe I understand half of the implications. It'd great to hear your inputs before I proceed implementing others.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 23 2024 at 15:44):

eagr edited a comment on PR #9896:

cargo run --features pulley -- wast --target pulley64 ./tests/misc_testsuite/simd/canonicalize-nan.wast -W nan-canonicalization

Seems passing. Is it how the test supposed to run?

About the fn naming, I'm just kinda going along with veq32x4 and friends. If you'd prefer, say, vlef32x4 over vlteqf32x4, or vueqf64x2 over vunoeqf64x2, I'm happy to change them.

And I haven't implemented all the float condcodes, just enough to get the tests pass. I did skim through the docs, but I don't believe I understand half of the implications. It'd great to hear your inputs before I proceed implementing others.

cc @alexcrichton

view this post on Zulip Wasmtime GitHub notifications bot (Dec 23 2024 at 17:44):

github-actions[bot] commented on PR #9896:

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "cranelift", "pulley"

Thus the following users have been cc'd because of the following labels:

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (Dec 24 2024 at 06:53):

eagr updated PR #9896.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 24 2024 at 12:13):

eagr updated PR #9896.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 27 2024 at 05:43):

alexcrichton commented on PR #9896:

Thanks for this! I think it might be best to cut down on some of these opcodes in Pulley though since wasm doesn't actually use many of the FloatCC::Unordered* orderings for example. I'd recommend having a pulley opcode for wasm-based orderings but those needed only for nan canonicalization for example I think should be implemented like other lowering rules on other platforms (e.g. using combinations of opcodes instead of one). If this ever becomes performance sensitive we can of course revisit.

I'd recommend taking a look at how the riscv64 backend does this for example

view this post on Zulip Wasmtime GitHub notifications bot (Dec 27 2024 at 05:44):

alexcrichton commented on PR #9896:

Oh I'll also note that another example is in https://github.com/bytecodealliance/wasmtime/pull/9884 (which I'm happy to merge your PR before mind and rebase around yours), which has another possible strategy for implementing some comparison-related opcodes here.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 27 2024 at 07:04):

eagr commented on PR #9896:

I didn't notice your PR. I couldn't see this one is contributing anything on top of yours, so I guess it's faster to just close this one to get out of the way. :)

view this post on Zulip Wasmtime GitHub notifications bot (Dec 27 2024 at 07:29):

eagr closed without merge PR #9896.


Last updated: Jan 24 2025 at 00:11 UTC