Add initial f16 and f128 support to the s390x backend

[beetrees]

This PR adds initial support for passing f16 and f128 values around to the s390x backend. Support is added for the load, store, bitcast, f16const and f128const CLIF instructions.

Note that the s390x ABI specification currently does not specify the ABI for f16. However, Clang recently added support for f16 in llvm/llvm-project#109164 (as opposed to LLVM just supporting it at the LLVM IR level) using a straightforward extrapolation of the ABI (passing f16 in floating point registers just like f32 and f64), so on that basis I've not put the f16 ABI behind the enable_llvm_abi_extensions setting.

f16/f128 issue: #8312

[cfallin]

cc @uweigand -- would you mind reviewing the s390x backend changes here? (Thanks!)

[github-actions]

Subscribe to Label Action

cc @cfallin, @fitzgen

This issue or pull request has been labeled: "cranelift", "cranelift:area:machinst", "isle"

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

• cfallin: isle
• fitzgen: isle

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

Learn more.

[uweigand]

Thanks for working on s390x! For f128, current hardware actually has two different ways of representing them - there's the "traditional" way of splitting an f128 value across a pair of 64-bit floating-point registers, but since z14 we can also hold f128 values in a single vector register, with a full set of arithmetic operations available.

This patch is based on the traditional FPR pair approach, but I would much prefer using single vector registers, for several reasons:

• z14 is the minimum architecture level for cranelift, so the VR-based instructions are always available
• Handling a single VR is much simpler than handling a pair of FPRs
• Specifically, while your patch hasn't run into this problem yet, once you actually want to use any of the traditional f128 arithmetic instructions, those only operate on architected pairs (N, N+2), not any two random FPRs. But the cranelift regalloc actually isn't capable of allocating pairs, so those would have to be hardcoded everywhere

Note that the one place where we'd still require pairs (even when using VRs everywhere else) is for function arguments and returns, as the ABI was defined for older systems. But for the ABI we have to hard-code registers anyway, so that should be much less of an issue. (For our own non-system ABIs, we could even chose to pass f128 in VR as well.)

LLVM (and GCC) will also use VRs to hold f128 if you build with -march=z14 or higher.

[beetrees]

Done. f128 is now stored in a single vector register.

Note that the one place where we'd still require pairs (even when using VRs everywhere else) is for function arguments and returns, as the ABI was defined for older systems. But for the ABI we have to hard-code registers anyway, so that should be much less of an issue. (For our own non-system ABIs, we could even chose to pass f128 in VR as well.)

I'm unsure what you mean by this; according to the s390x ABI specification f128 is always passed and returned indirectly.

[uweigand]

Done. f128 is now stored in a single vector register.

Thanks, I'll have a closer look shortly.

I'm unsure what you mean by this; according to the s390x ABI specification f128 is always passed and returned indirectly.

Sorry, I must have gotten confused. You're correct, of course.

[uweigand]

OK, this all LGTM now. Thanks again!

[cfallin]

Thanks for the review, @uweigand! Giving this an approval based on that, and merging.

[cfallin]

@alexcrichton it looks like the merge queue checks failed on a diff of a C++ header -- IIRC you had worked on this recently?

[alexcrichton]

I think that was a failure to download wasm.hh and it manifested as a weird error, so I'm going to re-queue, but I could very well be wrong...