saulecabrera edited issue #9766:
While reviewing https://github.com/bytecodealliance/wasmtime/pull/9762, I realized that in the case of 32-bit operands a sign-extension is required given that
cranelift-codegen
, only accepts 64-bit operands.The ARM64 documentation states [1], [2] that 32-bit operands for division are allowed.
[1]: https://developer.arm.com/documentation/ddi0596/2020-12/Base-Instructions/SDIV--Signed-Divide-
[2]: https://developer.arm.com/documentation/ddi0602/2024-09/Base-Instructions/UDIV--Unsigned-divide-Introducing support for 32-bit operands means that in Winch we can skip the extension sequence when dealing with 32-bit operands, similar th
As a side note, it seems that when migrating to ISLE the intention was to add support for 32-bit operands.
cc @alexcrichton / @cfallin I'm not entirely familiar with the development history of the Aarch64 backend, is there any other reason to be aware of when considering support for 32-bit operands?
cfallin commented on issue #9766:
I'm not aware of any reasons why we couldn't add 32-bit variants of the
div
instruction family; going all the way back to the original PR for the aarch64 backend it looks like I had only implementedSDiv64
andUDiv64
and added the extensions. Probably this is a case of "no one has had occasion to add it yet"...(Incidentally, x86-64 has 32-bit divides too; and on both architectures I'd expect that high-performance implementations would probably take ~half the latency for a 32-bit version; so not a small win for any benchmark with a divide in a critical path.)
saulecabrera edited issue #9766:
While reviewing https://github.com/bytecodealliance/wasmtime/pull/9762, I realized that in the case of 32-bit operands a sign-extension is required given that
cranelift-codegen
, only accepts 64-bit operands.The ARM64 documentation states [1], [2] that 32-bit operands for division are allowed.
[1]: https://developer.arm.com/documentation/ddi0596/2020-12/Base-Instructions/SDIV--Signed-Divide-
[2]: https://developer.arm.com/documentation/ddi0602/2024-09/Base-Instructions/UDIV--Unsigned-divide-Introducing support for 32-bit operands means that in Winch we can skip the extension sequence when dealing with 32-bit operands.
As a side note, it seems that when migrating to ISLE the intention was to add support for 32-bit operands.
cc @alexcrichton / @cfallin I'm not entirely familiar with the development history of the Aarch64 backend, is there any other reason to be aware of when considering support for 32-bit operands?
saulecabrera added the winch label to Issue #9766.
github-actions[bot] commented on issue #9766:
Subscribe to Label Action
cc @saulecabrera
<details>
This issue or pull request has been labeled: "winch"Thus the following users have been cc'd because of the following labels:
- saulecabrera: winch
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
MarinPostma commented on issue #9766:
I'd like to take a stab at that after I'm done with winch. Any guidance on how I should tackle that?
saulecabrera commented on issue #9766:
One approach could be to take a look at how similar instructions have been added in the past e.g., https://github.com/bytecodealliance/wasmtime/pull/8453
cfallin closed issue #9766:
While reviewing https://github.com/bytecodealliance/wasmtime/pull/9762, I realized that in the case of 32-bit operands a sign-extension is required given that
cranelift-codegen
, only accepts 64-bit operands.The ARM64 documentation states [1], [2] that 32-bit operands for division are allowed.
[1]: https://developer.arm.com/documentation/ddi0596/2020-12/Base-Instructions/SDIV--Signed-Divide-
[2]: https://developer.arm.com/documentation/ddi0602/2024-09/Base-Instructions/UDIV--Unsigned-divide-Introducing support for 32-bit operands means that in Winch we can skip the extension sequence when dealing with 32-bit operands.
As a side note, it seems that when migrating to ISLE the intention was to add support for 32-bit operands.
cc @alexcrichton / @cfallin I'm not entirely familiar with the development history of the Aarch64 backend, is there any other reason to be aware of when considering support for 32-bit operands?
Last updated: Dec 23 2024 at 12:05 UTC