bnjbvr
commented
4 years ago 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
github-actions[bot]
bjorn3
whitequark
jkshtj
jameysharp
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.