cranelift-codegen fails to compile without x86 support

[iximeow]

• What are the steps to reproduce the issue?
  • Build cranelift-codegen targeting only one architecture (as an example, clone https://github.com/iximeow/cautious-pancake and build it)
• What do you expect to happen?
  • Compilation should succeed.
• What does actually happen?
  • Compilation does not succeed.
• Which Cranelift version / commit hash / branch are you using?
  • 3179dcf (master)
• If relevant, can you include some extra information about your environment?
  • n/a - reproducible anywhere Cargo runs.

This was first mentioned by @stefson in this comment.

I agree with @bjorn3's assessment in reply. Since TLS access assumes a C ABI, would it make sense to just add is_call as an attribute to these opcodes? Edit: this depends on other questions like, can TlsGetAddr be hoisted in LICM? Eligible for DCE? And interaction with the verifier? Given that it includes a call I think this might be the right way to go about it. And since the call takes an argument in rdi, if there needs to be a signature for verifier reasons, it looks like we can synthesize one of the form (rdi) -> rax?

A wider concern: does anyone have ideas on how we'd build Cranelift under these different, more specific, feature flag combinations? I was surprised to learn cargo build --no-default-features --features std didn't work to show this, but that seems to be a consequence of this issue. It seems appropriate to have some test crates that build under feature flag combinations we want to support, so issues like this get caught in CI. It would raise build times a bit, but I'm not sure how much. Does that sound acceptable?

[bnjbvr]

This is now biting us in Spidermonkey too, where we only build the relevant backends, so this is high priority for us.

We could add supplementary builds with disabled features in automation, to make sure they don't get broken anymore.

[bjorn3]

I initially tried adding is_call, but that requires analyze_call to return a valid CallInfo. As the instructions in question are not normal calls and don't have a Signature, it is not possible to return a valid CallInfo.

can TlsGetAddr be hoisted in LICM? Eligible for DCE?

Yes and yes, I think.

And since the call takes an argument in rdi, if there needs to be a signature for verifier reasons, it looks like we can synthesize one of the form (rdi) -> rax?

How would that signature get assigned to the instruction? It is not possible to lower the instructions to libcalls, as they require a very specific combination of x86 instructions for the linker to handle it correctly.

was surprised to learn cargo build --no-default-features --features std didn't work to show this, but that seems to be a consequence of this issue.

During compilation the build script detects the current architecture and automatically enables support for it. (at least if there are no archs enabled through feature flags)

[bnjbvr]

So my current thinking is the following: since this can't be emulated properly with a call, maybe the proper way here is to add a new accessor on the opcode? I've got a wip patch that does this, with a new property called "clobbers_all_regs", and which is tested during register allocation in place of the opcode comparisons. I thought about other names, like "emulates_call", but this seems to be the most explicit, at the very least.

[bjorn3]

I've got a wip patch that does this, with a new property called "clobbers_all_regs"

👍

[bjorn3]

Was actually working on the same, but named it clobbers_all :)