[WIP] Add support for Windows x32 ABI

[whitequark]

As it stands the patch in this PR is as minimal as it is hair-raising, and it's really not going to be merged in the current state. However, with it and #1740 I can actually run simple programs on x32!

(The -Cpanic=abort, plus a dummy #[no_mangle] pub extern fn _Unwind_Resume() { unimplemented!() }, are there to work around the fact that Linux distributions all build MinGW with SjLj exceptions, but Rust expects a MinGW toolchain with DWARF exceptions.)

Let me explain the reasons this PR looks like it does.

First, currently target-lexicon considers Windows as always using fastcall. However that's not the case on x32, where C code uses cdecl by default, and Win32 APIs use stdcall by default. This is why Windows x32 is special-cased in cranelift in this PR. To fix this, I believe that default_calling_convention for Windows x32 should return cdecl so that it matches the behavior of the Rust c calling convention, but that's where we get to the second issue...

Second, there is actually no way to express "Windows cdecl" in either target-lexicon or cranelift. AFAICT this calling convention is functionally identical to the System V one; LLVM calls it ccc to avoid naming it in either a *nix-specific way ("System V") or a Windows-specific way ("cdecl"). The way this should be handled is purely subjective though (the options being "rename SystemV to Ccc", "rename SystemV to Cdecl", "add Cdecl as an alias of SystemV for Windows alone", and "do nothing and just use SystemV on Windows x32") so I'm going to implement whatever the maintainers ask me to.

[github-actions]

Subscribe to Label Action

cc @bnjbvr

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.

[abrown]

@whitequark, why did you have to --enable-simd?

[whitequark]

@whitequark, why did you have to --enable-simd?

This is a limitation of the x86_32 backend. At the moment, shifts of 64-bit values are legalized to PSLLQ/PSRLQ (#1612) but there's no other applicable legalization rule at all. I wasn't sure what's a good way to legalize 64-bit shifts on 32-bit platforms so I went with the SIMD route that was similar to existing code. Suggestions for a better approach very much welcome!

[sunfishcode]

the options being "rename SystemV to Ccc", "rename SystemV to Cdecl", "add Cdecl as an alias of SystemV for Windows alone", and "do nothing and just use SystemV on Windows x32"

"do nothing and just use SystemV on Windows x32" and "rename SystemV to Cdecl" sound like they might confuse people; at least, it would probably confuse me if I hadn't just read the rest of the post above :-).

I have a mild preference for "add Cdecl as an alias of SystemV for Windows alone", but I also wouldn't be opposed to "rename SystemV to Ccc" (and introduce a new variant for x86-64).

[whitequark]

@whitequark, why did you have to --enable-simd?

#1787 fixes that.

[whitequark]

Triage: I believe that with the removal of x86_32 backend this PR is no longer relevant.