Get Cranelifted

[workingjubilee]

Per the conversation on Zulip in t-compiler and project-portable-simd, we are going to find Cranelift landing a direct challenge to our landing in std, because the last one in is a rotten egg has to implement support for the other... but while we could "race" them, it seems integration might require a total redesign anyways. So, collaboration! But we need to

0. Figure out what Cranelift needs from us
1. Figure out what we need from Cranelift
2. Figure out what additional consequences landing std::simd has for Cranelift support
3. Figure out what additional consequences landing Cranelift support has for std::simd
4. Solve all that

@bjorn3 said:

I hope most if not all of the operations used by portable simd could use (newly introduced) simd_* platform intrinsics that are architecture and vector size independent. This would allow easy emulation of them implemented once per operation.

This has led to some immediate questions:

0. What exactly are "platform-intrinsics" supposed to be? Our current understanding is that they're LLVM ops... but Cranelift isn't LLVM, obviously. So...
1. What changes about them when moving from LLVM to Cranelift?
2. What does this do for SIMD FFI?
3. Can we find a way around the SIMD FFI question?

[Lokathor]

I'd like to explicitly note that this doesn't (or shouldn't) have any impact on the public api of the crate. This consideration is purely for the internals.

[workingjubilee]

Total redesign of the backend only, yes.

Though I should note that if our public API makes certain promises about how it lowers that it can't keep, then we effectively are breaking our public API anyways, just in a way that is harder to discern.

[Lokathor]

That's why I was so resistant to the idea that we'd say what core::arch intrinsics a given core::simd lowers to, even in the obvious cases. Because we really should be guaranteeing nothing in that area.

[workingjubilee]

A bunch of discussion on this issue happened and none of it got adequately summarized here. I will attempt to do so in very brief.

Basically, this problem more or less goes away if we can make sure that the library does not tap into codegen-related things (LLVM intrinsic linkages, etc.) directly, and instead uses only functions provided directly from rustc. Whatever is in rustc has to be implemented by cranelift*, but that is somewhat simpler. Accordingly, I removed those in #47, which also fixed other issues. This means that the powers of rustc have to be enhanced where relevant, since rustc does not have the ability to do everything we need. See #46.

In order to remove this blockage on a semi-permanent basis for any codegen backends in the present or future, rust-lang/compiler-team#381 was opened as a proposal for Rust-driven (fallback|reference) implementations of various operations to live in the compiler, for use in codegen.

• i.e. the "platform intrinsics" exist because they had backend support in LLVM and can be lowered in a fairly straightforward fashion to LLVM IR in codegen. Cranelift thus also has to implement these, but Cranelift doesn't have to actually lower the "platform intrinsics" in the same way, and thus does not have to match the LLVM API 1:1, nor does it have to match "the LLVM API" even, as opposed to the subset we are concerned about. This decouples the two codegen backends for SIMD instructions by making rustc's platform intrinsics into their common attachment point.