-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support x86-32 in new instruction selection framework #1980
Comments
Thanks for opening an issue! Sharing codeThe current encoding machinery is sufficient to support all the x86 32 and 64 bits instructions up to SSE4.2 (i.e., nothing has been done for VEX yet). Most encodings can be reused on 32 bits (of course, without the 64-bit mode); some specific encodings and addressing modes are not available in 32-bits mode (e.g. RIP-relative addressing). Ideally, most of the encoding code could be shared between the two architectures, with an Alternatively, we could just duplicate all the Inst variants, so that each target has precisely what it can do. Even if this implies some code duplication, this should stay reasonably well-contained over time: code emitting encodings tends to remain stable over time, once it's been written (and maybe fixed once or twice). Since this encoding code is still in the process of being written, it might be good to wait for stabilization before jumping into implementing a new target derived from it. Legalizing IRAt this point, there's not a good story for transforming sequences of operations involving types that are not natively supported by the platform: be it i128 or aarch64/x64, or i64 on on x86 32 bits. We'd probably need something like lightweight legalizations to make this maintainable over time. ABIs32-bits ABIs would be one more work item to do, since the ABIs are quite different. This isn't quite complicated, but it requires careful testing to be sure not to make an error there. In a nutshell, there's nothing that's too complicated. I'm not quite sure of the best way to share code yet. |
|
It would be helpful and informative if the README.md at https://github.com/bytecodealliance/wasmtime including an unambiguous and conspicuous header and language that states x86 32 bit architecture is not (currently) supported, so that users do not run
or try https://wasi.dev/polyfill/ using instructions at https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-tutorial.md expecting the code to work. |
Subscribe to Label Actioncc @bnjbvr
This issue or pull request has been labeled: "cranelift"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
I think this can be closed. |
How can I test 32-bit x86 support?
|
The new x64 backend doesn't have 32bit support yet. |
That's exactly what this issue is about, no? |
Oops, interpreted x86 as x86_64 instead of 32bit x86. |
I was recently pointed to fastly/Viceroy#200 where it seems some folks are trying to compile Wasmtime (via Viceroy) for Windows x86-32 and the failures may not be loud enough. I've tried to reproduce this cross-compiling to i686-pc-windows-gnu from Linux and hit build failures (as expected) in several places. Nevertheless, while trying to discern what others may be attempting, I noticed some dead x86-32-specific code in our repo, and figured it would be a good idea to clean this up. Otherwise, it (i) sends some mixed messages -- "hey look, this codebase does support x86-32" -- and (ii) keeps untested code around, which is generally not great. This PR removes x86-32-specific cases in traphandlers and unwind code, and Cranelift's native feature detection. It adds helpful compile-error messages in a few cases. If we ever support x86-32 (contributors welcome! The big missing piece is Cranelift support; see bytecodealliance#1980), these compile errors and git history should be enough to recover any knowledge we are now encoding in the source. I left the x86-32 support in `wasmtime-fiber` alone because that seems like a bit of a special case -- foundation library, separate from the rest of Wasmtime, with specific care to provide a (presumably working) full 32-bit version.
I was recently pointed to fastly/Viceroy#200 where it seems some folks are trying to compile Wasmtime (via Viceroy) for Windows x86-32 and the failures may not be loud enough. I've tried to reproduce this cross-compiling to i686-pc-windows-gnu from Linux and hit build failures (as expected) in several places. Nevertheless, while trying to discern what others may be attempting, I noticed some dead x86-32-specific code in our repo, and figured it would be a good idea to clean this up. Otherwise, it (i) sends some mixed messages -- "hey look, this codebase does support x86-32" -- and (ii) keeps untested code around, which is generally not great. This PR removes x86-32-specific cases in traphandlers and unwind code, and Cranelift's native feature detection. It adds helpful compile-error messages in a few cases. If we ever support x86-32 (contributors welcome! The big missing piece is Cranelift support; see bytecodealliance#1980), these compile errors and git history should be enough to recover any knowledge we are now encoding in the source. I left the x86-32 support in `wasmtime-fiber` alone because that seems like a bit of a special case -- foundation library, separate from the rest of Wasmtime, with specific care to provide a (presumably working) full 32-bit version.
* Wasmtime+Cranelift: strip out some dead x86-32 code. I was recently pointed to fastly/Viceroy#200 where it seems some folks are trying to compile Wasmtime (via Viceroy) for Windows x86-32 and the failures may not be loud enough. I've tried to reproduce this cross-compiling to i686-pc-windows-gnu from Linux and hit build failures (as expected) in several places. Nevertheless, while trying to discern what others may be attempting, I noticed some dead x86-32-specific code in our repo, and figured it would be a good idea to clean this up. Otherwise, it (i) sends some mixed messages -- "hey look, this codebase does support x86-32" -- and (ii) keeps untested code around, which is generally not great. This PR removes x86-32-specific cases in traphandlers and unwind code, and Cranelift's native feature detection. It adds helpful compile-error messages in a few cases. If we ever support x86-32 (contributors welcome! The big missing piece is Cranelift support; see #1980), these compile errors and git history should be enough to recover any knowledge we are now encoding in the source. I left the x86-32 support in `wasmtime-fiber` alone because that seems like a bit of a special case -- foundation library, separate from the rest of Wasmtime, with specific care to provide a (presumably working) full 32-bit version. * Remove some extraneous compile_error!s, already covered by others.
@tschneidereit @whitequark @cfallin @bjorn3 I would be interested in picking this up. I still need to dive deeper to come up with a concrete plan, but would one of you (or someone you could connect me to) be willing to mentor me? |
Hi @Jain98! We're always happy to answer questions and help however we can. I'd encourage you to join the Since all our current backends are 64-bit, we haven't necessarily designed everything to support 32-bit targets well. We'd like to fix that, but in the meantime just be aware that you may find some things are harder than they should be. There's been recent discussion about that in #5572, and the advice there applies here too. |
Hi @jameysharp, thanks for replying and a link to a recent discussion. I've already joined the cranelift zulip chat, but figured I'd start here as it seemed more intentional. It at least looks like there's already an existing backend for x86-32, no? If yes, could you could point me to it? That might be a good starting point for me. |
There used to be an x86-32 backend, but it was unmaintained and eventually got in the way of working on the rest of Cranelift, so it was deleted. If I'm reading the history correctly there have been at least two complete rewrites of how Cranelift backends are written since the last time that backend worked, so digging it up out of the git history probably won't help you much. Instead I'd suggest looking at the current x86-64 backend, which is mostly in |
We don't currently have fully working x86 support, but we have a backend in-tree that's largely completely. However, it uses the old instructions selection framework, and as described in #1936, Cranelift is in the process of switching to a new one. While the old framework won't be removed until quite a bit later, that means that not much work will go into it anymore, and that any investments into backends based on it will become obsolete.
We should investigate the best approach to supporting x86 in the new framework.
There's active work going on to implement x64 support in the new framework, but no current effort around x86. In #1789 @whitequark mentions that she'd be happy to contribute to x86 support in the new framework, but only if the general support for targeting x86 exists.
@bnjbvr @julian-seward1, can you comment on what the best approach to take here would be? I understand that this isn't something that's high on your priority list, so as a first step we should just get a clearer picture of what this could look like, and the effort required.
The text was updated successfully, but these errors were encountered: