Support x86-32 in new instruction selection framework

[tschneidereit]

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.

[bnjbvr]

Thanks for opening an issue!

Sharing code

The 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 Inst enum for instructions that are common to both architectures; each of x86_64 and x86-32bits would then have their own Inst enum as well, with a particular Shared variant that would be dynamically dispatch most queries / calls to the shared Inst enum. It would mean that the 64-bits and 32-bits backends would have special code to handle the shared encodings (e.g. when printing out the instructions and registers, when handling supported operand sizes,...) so it might become a bit messy. Moreover, the code for these two architectures would be scattered in more places. Spidermonkey has tried to enforce code sharing between these two architectures, and it's made the code difficult to follow sometimes (it tends to force low-level abstractions that add unnecessary layers to the code). But we wouldn't need to duplicate work.

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 IR

At 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.

ABIs

32-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.

[guest271314]

Error: Sorry! Wasmtime currently only provides pre-built binaries for x86_64 architectures.

[guest271314]

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

$ curl https://wasmtime.dev/install.sh -sSf | bash

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.

[github-actions]

Subscribe to Label Action

cc @bnjbvr

Details

This issue or pull request has been labeled: "cranelift"

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

• bnjbvr: cranelift

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

Learn more.

[bjorn3]

I think this can be closed.

[whitequark]

How can I test 32-bit x86 support? --target i686-unknown-linux-gnu doesn't seem to work for example:

thread 'main' panicked at 'host machine is not a supported target: "unsupported architecture"', crates/jit/src/native.rs:6:33

[bjorn3]

The new x64 backend doesn't have 32bit support yet.

[whitequark]

That's exactly what this issue is about, no?

[bjorn3]

Oops, interpreted x86 as x86_64 instead of 32bit x86.