Support s390x z13 vector ABI

[taiki-e]

cc #130869

This resolves the following fixmes:

• rust/compiler/rustc_target/src/abi/call/s390x.rs

  Lines 1 to 2 in 58420a0

  	// FIXME: The assumes we're using the non-vector ABI, i.e., compiling
  	// for a pre-z13 machine or using -mno-vx.

• rust/compiler/rustc_target/src/spec/targets/s390x_unknown_linux_gnu.rs

  Lines 9 to 11 in 58420a0

  	// FIXME: The ABI implementation in abi/call/s390x.rs is for now hard-coded to assume the no-vector
  	// ABI. Pass the -vector feature string to LLVM to respect this assumption.
  	base.features = "-vector".into();

Refs: Section 1.2.3 "Parameter Passing" and section 1.2.5 "Return Values" in ELF Application Binary Interface s390x Supplement, Version 1.6.1 (lzsabi_s390x.pdf in https://github.com/IBM/s390x-abi/releases/tag/v1.6.1)

This PR extends #127731 (merged) 's ABI check to handle cases where vector target feature is disabled.
If we do not do ABI check, we run into the ABI problems as described in #116558 and #130869 (comment), and the problem of the compiler generating strange code (#131586 (comment)).

cc @uweigand

@rustbot label +O-SystemZ +A-ABI

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jieyouxu]

r? compiler

[uweigand]

In addition to the problem mentioned inline, we should also verify that building with soft-float works as expected. This option implicitly disables any use of floating-point or vector registers, and therefore also disables use of the vector facility. I believe the LLVM back-end should handle that logic correctly, but it would be good to have the test check.

[uweigand]

It's also incorrect. Without the vector feature, vector types of any length are supposed to be passed via implicit reference, which in the case means a pointer in %r2. The body of the function should simply be:

lg %r2, 0(%r2)

Not sure what exactly the compiler is doing here, but it appears to have scalarized the input and pass it as 8 distinct one-byte arguments ...

[taiki-e]

This case and soft-float case should eventually result in a compilation error once the ABI check is implemented, and I will add UI tests for these cases once the ABI check is implemented.

[uweigand]

Fair enough. I just wanted to point out the incorrect code, in case we do end up going back to supporting the no-vector case.

[bors]

☔ The latest upstream changes (presumably #131747) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #127731) made this pull request unmergeable. Please resolve the merge conflicts.

[taiki-e]

I added a soft-float case per #131586 (review), but the soft-float target feature affects the float ABI, so its use with the -C target-feature flag will likely be deprecated (#116344).

Also, the soft-float target feature is recognized by LLVM but not by rustc, so I get the following warning:

warning: unknown and unstable feature specified for `-Ctarget-feature`: `soft-float`
  |
  = note: it is still passed through to the codegen backend, but use of this feature might be unsound and the behavior of this feature can change in the future

https://godbolt.org/z/x75bPveh5

[taiki-e]

(Btw, it seems other architecture's soft-float targets also explicitly disable SIMD-related features)

rust/compiler/rustc_target/src/spec/targets/x86_64_unknown_none.rs

Line 23 in 6faf0bd

features: "-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-avx,-avx2,+soft-float".into(),

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[taiki-e]

Rewritten based on the merged #127731.

@rustbot label +S-waiting-on-review, -S-blocked

[taiki-e]

Hmm, #127731 will likely be reverted for now: #132152

@rustbot label +S-blocked

[compiler-errors]

Sorry for the churn @taiki-e 😭

[bors]

☔ The latest upstream changes (presumably #132152) made this pull request unmergeable. Please resolve the merge conflicts.