Stream: git-wasmtime

Topic: wasmtime / issue #4782 cranelift: Add LibCalls to the int...

view this post on Zulip Wasmtime GitHub notifications bot (Aug 25 2022 at 15:03):

github-actions[bot] commented on issue #4782:

Subscribe to Label Action

cc @fitzgen

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

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 (Aug 25 2022 at 19:35):

jameysharp commented on issue #4782:

Huh. I was going to suggest that if there are libcalls with undefined behavior on some inputs then we should be limiting what we pass them to ensure that we only use them in ways consistent with the semantics we want. But I went to check how libcalls like UdivI64 or IshlI64 are used, and as far as I can tell, they aren't. We should probably remove them, yeah?

These libcalls are constructed in Rust source:

While these are constructed in the x64 ISLE rules (but not any other backend?):

LibCall::for_inst would construct some other libcalls, but apparently its only use was removed last year in bae4ec642798ff448ca88eab771b6fcea71e7884, so I've excluded it from the above lists.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 25 2022 at 19:42):

afonso360 commented on issue #4782:

But I went to check how libcalls like UdivI64 or IshlI64 are used, and as far as I can tell, they aren't. We should probably remove them, yeah?

That sounds like a good idea.

While these are constructed in the x64 ISLE rules (but not any other backend?):

Yeah, x86 doesn't have native instructions for these without extensions, so we have to lower them as libcalls if some extensions are disabled. I only know about AArch64 but they have equivalents for these in the base ISA. Not sure about s390x but i assume its the same

We can emit something like CeilF32 or any other really. The only downside being that it puts us in the "Changes fuzzer input do not merge" category. I'm okay with that.

I think the float libcalls don't trap at all.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 26 2022 at 14:06):

afonso360 commented on issue #4782:

I've changed this in a few ways, and since we are going to change the input of the fuzzer we might as well do it properly and generate multiple libcalls, so we now do that.

I've also removed the unused libcalls and a few accessory bits.

Last updated: Nov 22 2024 at 16:03 UTC