Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly #130630

taiki-e · 2024-09-20T17:42:39Z

This supports clobber_abi which is one of the requirements of stabilization mentioned in #93335.

This also supports vector registers (as vreg) and access registers (as areg) as clobber-only, which need to support clobbering of them to implement clobber_abi.

Refs:

"1.2.1.1. Register Preservation Rules" section 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)
Register definition in LLVM:
- Vector registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L249
- Access registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L332

I have three questions:

ELF Application Binary Interface s390x Supplement says that cc (condition code, bits 18-19 of PSW) is "Volatile".
However, we do not have a register class for cc and instead mark cc as clobbered unless preserves_flags is specified (Mark s390x condition code register as clobbered in inline assembly #111331).
Therefore, in the current implementation, if both preserves_flags and clobber_abi are specified, cc is not marked as clobbered. Is this okay? Or even if preserves_flags is used, should cc be marked as clobbered if clobber_abi is used? UPDATE: resolved Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly #130630 (comment)
ELF Application Binary Interface s390x Supplement says that pm (program mask, bits 20-23 of PSW) is "Cleared".
There does not appear to be any registers associated with this in either LLVM or GCC, so at this point I don't see any way other than to just ignore it. Is this okay as-is? UPDATE: resolved Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly #130630 (comment)
Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and reg_addr, which uses the “a” constraint (Support reg_addr register class in s390x inline assembly #119431)...

Note:

GCC seems to recognize only a0 and a1, and using a[2-15] causes errors.
Given that cg_gcc has a similar problem with other architecture (x86_64 asm: Build error when using r[8-15]b rustc_codegen_gcc#485), I don't feel this is a blocker for this PR, but it is worth mentioning here.
vreg should be able to accept #[repr(simd)] types as input if the vector target feature added in rustc_target: add known safe s390x target features #127506 is enabled, but core_arch has no s390x vector type and both #[repr(simd)] and core::simd are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... S390x inline asm #88245 (comment)

cc @uweigand

r? @Amanieu

@rustbot label +O-SystemZ +A-inline-assembly

…0x inline assembly

rustbot · 2024-09-20T17:42:49Z

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

uweigand · 2024-09-23T11:21:15Z

This supports clobber_abi which is one of the requirements of stabilization mentioned in #93335.

Thanks for working on SystemZ support for this!

ELF Application Binary Interface s390x Supplement says that cc (condition code, bits 18-19 of PSW) is "Volatile".
However, we do not have a register class for cc and instead mark cc as clobbered unless preserves_flags is specified (Mark s390x condition code register as clobbered in inline assembly #111331).
Therefore, in the current implementation, if both preserves_flags and clobber_abi are specified, cc is not marked as clobbered. Is this okay? Or even if preserves_flags is used, should cc be marked as clobbered if clobber_abi is used?

As I read the Rust inline-asm documention (https://doc.rust-lang.org/stable/reference/inline-assembly.html), this looks OK to me. We have the statement:

Any registers not specified as outputs must have the same value upon exiting the asm block as they had on entry, otherwise behavior is undefined.
- This only applies to registers which can be specified as an input or output. Other registers follow target-specific rules.

Since the flags register cannot be specified as an input or output, the target-specific rules exception applies. For the flags register specifically, we then have the following rules:

These flags registers must be restored upon exiting the asm block if the preserves_flags option is set: 
- [list per architecture]

We can define this for SystemZ, and the definition that makes sense is to preserve the full CC value. (And I guess also some of the flags in the floating-point control register, specifically the exception masks and rounding modes. But since we don't really model the FPC, we may have to just ignore that part for now.)

Finally, looking at the list of clobbered registers on the other supported targets shows that for none of them, clobber_abi affects the flags register(s). So it seems intentional that clobber_abi and preserves_flags are somewhat orthogonal; it would seem to make sense to follow that precedent on SystemZ as well.

ELF Application Binary Interface s390x Supplement says that pm (program mask, bits 20-23 of PSW) is "Cleared".
There does not appear to be any registers associated with this in either LLVM or GCC, so at this point I don't see any way other than to just ignore it. Is this okay as-is?

Yes, that should be fine to ignore.

Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and reg_addr, which uses the “a” constraint (Support reg_addr register class in s390x inline assembly #119431)...

Not sure exactly what the Rust convention here is. I'd be fine with "areg", but maybe "acreg" or something might be clearer?

GCC seems to recognize only a0 and a1, and using a[2-15] causes errors.
Given that cg_gcc has a similar problem with other architecture (x86_64 asm: Build error when using r[8-15]b rustc_codegen_gcc#485), I don't feel this is a blocker for this PR, but it is worth mentioning here.

Interesting, thanks for pointing this out. This should be fixed in GCC at some point, but it's probably not particularly important. I agree it should not block this PR.

vreg should be able to accept #[repr(simd)] types as input if the vector target feature added in rustc_target: add known safe s390x target features #127506 is enabled, but core_arch has no s390x vector type and both #[repr(simd)] and core::simd are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... S390x inline asm #88245 (comment)

Actually, the situation has improved: the problem I pointed out in that last comment has been fixed in LLVM 16, which now always uses the same data_layout string, no matter whether the vector feature is enabled or not:
https://releases.llvm.org/16.0.0/docs/ReleaseNotes.html#changes-to-the-systemz-backend

Assuming rustc is now always built with LLVM 16 or later, we can drop the code that forces the vector feature to be always off, which would enable making general use of vector facilities if enabled. This would include fully supporting the vreg class for inline asm as well as enabling auto-SIMD and possibly even defining a set of platform-specific vector intrinsics.

taiki-e · 2024-09-26T04:13:32Z

ELF Application Binary Interface s390x Supplement says that cc (condition code, bits 18-19 of PSW) is "Volatile".
However, we do not have a register class for cc and instead mark cc as clobbered unless preserves_flags is specified (Mark s390x condition code register as clobbered in inline assembly #111331).
Therefore, in the current implementation, if both preserves_flags and clobber_abi are specified, cc is not marked as clobbered. Is this okay? Or even if preserves_flags is used, should cc be marked as clobbered if clobber_abi is used?

As I read the Rust inline-asm documention (https://doc.rust-lang.org/stable/reference/inline-assembly.html), this looks OK to me. We have the statement:
Any registers not specified as outputs must have the same value upon exiting the asm block as they had on entry, otherwise behavior is undefined.
- This only applies to registers which can be specified as an input or output. Other registers follow target-specific rules.
Since the flags register cannot be specified as an input or output, the target-specific rules exception applies. For the flags register specifically, we then have the following rules:
These flags registers must be restored upon exiting the asm block if the preserves_flags option is set: 
- [list per architecture]
We can define this for SystemZ, and the definition that makes sense is to preserve the full CC value. (And I guess also some of the flags in the floating-point control register, specifically the exception masks and rounding modes. But since we don't really model the FPC, we may have to just ignore that part for now.)

Finally, looking at the list of clobbered registers on the other supported targets shows that for none of them, clobber_abi affects the flags register(s). So it seems intentional that clobber_abi and preserves_flags are somewhat orthogonal; it would seem to make sense to follow that precedent on SystemZ as well.

Thanks for looking into this! After reading your comment I agree that this is okay as is (clobber_abi` doesn't t affect the flags registers).

ELF Application Binary Interface s390x Supplement says that pm (program mask, bits 20-23 of PSW) is "Cleared".
There does not appear to be any registers associated with this in either LLVM or GCC, so at this point I don't see any way other than to just ignore it. Is this okay as-is?

Yes, that should be fine to ignore.

Thanks for confirming!

Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and reg_addr, which uses the “a” constraint (Support reg_addr register class in s390x inline assembly #119431)...

Not sure exactly what the Rust convention here is. I'd be fine with "areg", but maybe "acreg" or something might be clearer?

If there is a name familiar to people familiar with s390x, I would have preferred to use it, but if there is not, areg, which uses the first letter of the register name, may actually be appropriate since it is also consistent with other register class names such as vreg and freg.

vreg should be able to accept #[repr(simd)] types as input if the vector target feature added in rustc_target: add known safe s390x target features #127506 is enabled, but core_arch has no s390x vector type and both #[repr(simd)] and core::simd are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... S390x inline asm #88245 (comment)

Actually, the situation has improved: the problem I pointed out in that last comment has been fixed in LLVM 16, which now always uses the same data_layout string, no matter whether the vector feature is enabled or not: https://releases.llvm.org/16.0.0/docs/ReleaseNotes.html#changes-to-the-systemz-backend

Assuming rustc is now always built with LLVM 16 or later, we can drop the code that forces the vector feature to be always off, which would enable making general use of vector facilities if enabled. This would include fully supporting the vreg class for inline asm as well as enabling auto-SIMD and possibly even defining a set of platform-specific vector intrinsics.

Thanks for the info! The current minimum external LLVM version is 18 (#130487), so I thought that the explicit disabling of the vector feature could be removed, but reading the target spec code, it seems that there is actually another issue that needs to be resolved...

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

Lines 9 to 12 in 9e394f5

    
           // FIXME: The ABI implementation in cabi_s390x.rs is for now hard-coded to assume the no-vector 
        
           // ABI. Pass the -vector feature string to LLVM to respect this assumption. On LLVM < 16, we 
        
           // also strip v128 from the data_layout below to match the older LLVM's expectation. 
        
           base.features = "-vector".into();

(I think it is off topic to continue talking about this here, so I opened #130869 which tracks the status of vector facilities support.)

uweigand · 2024-09-30T15:25:05Z

Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and reg_addr, which uses the “a” constraint (Support reg_addr register class in s390x inline assembly #119431)...

Not sure exactly what the Rust convention here is. I'd be fine with "areg", but maybe "acreg" or something might be clearer?

If there is a name familiar to people familiar with s390x, I would have preferred to use it, but if there is not, areg, which uses the first letter of the register name, may actually be appropriate since it is also consistent with other register class names such as vreg and freg.

Well, what should be familiar is the term "access register" as well as the short form AR, which parallels the short forms GPR (general-purpose register), FPR (floating-point register), VR (vector register) and CR (control register). There is no generally-known term "areg", but then there is no generally-known term "freg" or "vreg" either. But given this way of forming the name, it should be clear what is meant by "areg".

In any case, ARs by any name are basically never used on Linux anyway - sort of similar to segment registers on 64-bit Intel Linux. (With the exception of the toolchain using %a0/%a1 as thread-local pointer.)

Thanks for the info! The current minimum external LLVM version is 18 (#130487), so I thought that the explicit disabling of the vector feature could be removed, but reading the target spec code, it seems that there is actually another issue that needs to be resolved...

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

Lines 9 to 12 in 9e394f5

// FIXME: The ABI implementation in cabi_s390x.rs is for now hard-coded to assume the no-vector

// ABI. Pass the -vector feature string to LLVM to respect this assumption. On LLVM < 16, we

// also strip v128 from the data_layout below to match the older LLVM's expectation.

base.features = "-vector".into();

(I think it is off topic to continue talking about this here, so I opened #130869 which tracks the status of vector facilities support.)

Thanks! Will reply there.

Amanieu · 2024-10-01T08:35:44Z

I'm not too concerned about the areg and vreg names since they are clobber-only: that means that they can't actually be specified as a register class in asm!, at most they would appear in diagnostics.

@bors r+

bors · 2024-10-01T08:35:47Z

📌 Commit fa125e2 has been approved by Amanieu

It is now in the queue for this repository.

…llaumeGomez Rollup of 5 pull requests Successful merges: - rust-lang#130630 (Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly) - rust-lang#131042 (Instantiate binders in `supertrait_vtable_slot`) - rust-lang#131079 (Update wasm-component-ld to 0.5.9) - rust-lang#131085 (make test_lots_of_insertions test take less long in Miri) - rust-lang#131088 (add fixme to remove LLVM_ENABLE_TERMINFO when minimal llvm version is 19) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#130630 - taiki-e:s390x-clobber-abi, r=Amanieu Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in rust-lang#93335. This also supports vector registers (as `vreg`) and access registers (as `areg`) as clobber-only, which need to support clobbering of them to implement clobber_abi. Refs: - "1.2.1.1. Register Preservation Rules" section 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) - Register definition in LLVM: - Vector registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L249 - Access registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L332 I have three questions: - ~~ELF Application Binary Interface s390x Supplement says that `cc` (condition code, bits 18-19 of PSW) is "Volatile". However, we do not have a register class for `cc` and instead mark `cc` as clobbered unless `preserves_flags` is specified (rust-lang#111331). Therefore, in the current implementation, if both `preserves_flags` and `clobber_abi` are specified, `cc` is not marked as clobbered. Is this okay? Or even if `preserves_flags` is used, should `cc` be marked as clobbered if `clobber_abi` is used?~~ UPDATE: resolved rust-lang#130630 (comment) - ~~ELF Application Binary Interface s390x Supplement says that `pm` (program mask, bits 20-23 of PSW) is "Cleared". There does not appear to be any registers associated with this in either [LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td) or [GCC](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L407-L431), so at this point I don't see any way other than to just ignore it. Is this okay as-is?~~ UPDATE: resolved rust-lang#130630 (comment) - Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and `reg_addr`, which uses the “a” constraint (rust-lang#119431)... Note: - GCC seems to [recognize only `a0` and `a1`](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L428-L429), and using `a[2-15]` [causes errors](https://godbolt.org/z/a46vx8jjn). Given that cg_gcc has a similar problem with other architecture (rust-lang/rustc_codegen_gcc#485), I don't feel this is a blocker for this PR, but it is worth mentioning here. - `vreg` should be able to accept `#[repr(simd)]` types as input if the `vector` target feature added in rust-lang#127506 is enabled, but core_arch has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... rust-lang#88245 (comment) cc `@uweigand` r? `@Amanieu` `@rustbot` label +O-SystemZ

Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335. This also supports vector registers (as `vreg`) and access registers (as `areg`) as clobber-only, which need to support clobbering of them to implement clobber_abi. Refs: - "1.2.1.1. Register Preservation Rules" section 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) - Register definition in LLVM: - Vector registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L249 - Access registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L332 I have three questions: - ~~ELF Application Binary Interface s390x Supplement says that `cc` (condition code, bits 18-19 of PSW) is "Volatile". However, we do not have a register class for `cc` and instead mark `cc` as clobbered unless `preserves_flags` is specified (rust-lang/rust#111331). Therefore, in the current implementation, if both `preserves_flags` and `clobber_abi` are specified, `cc` is not marked as clobbered. Is this okay? Or even if `preserves_flags` is used, should `cc` be marked as clobbered if `clobber_abi` is used?~~ UPDATE: resolved rust-lang/rust#130630 (comment) - ~~ELF Application Binary Interface s390x Supplement says that `pm` (program mask, bits 20-23 of PSW) is "Cleared". There does not appear to be any registers associated with this in either [LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td) or [GCC](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L407-L431), so at this point I don't see any way other than to just ignore it. Is this okay as-is?~~ UPDATE: resolved rust-lang/rust#130630 (comment) - Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and `reg_addr`, which uses the “a” constraint (rust-lang/rust#119431)... Note: - GCC seems to [recognize only `a0` and `a1`](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L428-L429), and using `a[2-15]` [causes errors](https://godbolt.org/z/a46vx8jjn). Given that cg_gcc has a similar problem with other architecture (#485), I don't feel this is a blocker for this PR, but it is worth mentioning here. - `vreg` should be able to accept `#[repr(simd)]` types as input if the `vector` target feature added in rust-lang/rust#127506 is enabled, but core_arch has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... rust-lang/rust#88245 (comment) cc `@uweigand` r? `@Amanieu` `@rustbot` label +O-SystemZ

…rkingjubilee Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in rust-lang#93335. This basically does a similar thing I did in rust-lang#130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le. - This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`. - `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR. - See rust-lang#131551 (which is based on this PR) for a PR to implement this. - (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.) Refs: - PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf) - PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL) - PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/) - AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming) - Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189 If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`: - The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile). - As for GPR, only the registers we are treating as reserved are slightly different - r0, r3-r12 are volatile - r1(sp, reserved), r14-31 are nonvolatile - r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs) - r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX) - As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2. - As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](rust-lang#131341 (comment))) in AIX: > When the default Vector enabled mode is used, these registers are reserved and must not be used. > In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls I left [FIXME comment about PPC32 SysV](rust-lang#131341 (comment)) and added ABI check for AIX. - As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX - As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved. We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.) Replaces rust-lang#111335 and rust-lang#124279 cc `@ecnelises` `@bzEq` `@lu-zero` r? `@Amanieu` `@rustbot` label +O-PowerPC +A-inline-assembly [^r13]: callee-saved, according to [LLVM](https://github.com/llvm/llvm-project/blob/6a6af0246bd2d68291582e9aefc0543e5c6102fe/llvm/lib/Target/PowerPC/PPCCallingConv.td#L322) and [GCC](https://github.com/gcc-mirror/gcc/blob/a9173a50e7e346a218323916e4d3add8552529ae/gcc/config/rs6000/rs6000.h#L859).

…ingjubilee Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in rust-lang#93335. This basically does a similar thing I did in rust-lang#130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le. - This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`. - `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR. - See rust-lang#131551 (which is based on this PR) for a PR to implement this. - (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.) Refs: - PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf) - PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL) - PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/) - AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming) - Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189 If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`: - The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile). - As for GPR, only the registers we are treating as reserved are slightly different - r0, r3-r12 are volatile - r1(sp, reserved), r14-31 are nonvolatile - r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs) - r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX) - As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2. - As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](rust-lang#131341 (comment))) in AIX: > When the default Vector enabled mode is used, these registers are reserved and must not be used. > In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls I left [FIXME comment about PPC32 SysV](rust-lang#131341 (comment)) and added ABI check for AIX. - As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX - As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved. We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.) Replaces rust-lang#111335 and rust-lang#124279 cc `@ecnelises` `@bzEq` `@lu-zero` r? `@Amanieu` `@rustbot` label +O-PowerPC +A-inline-assembly [^r13]: callee-saved, according to [LLVM](https://github.com/llvm/llvm-project/blob/6a6af0246bd2d68291582e9aefc0543e5c6102fe/llvm/lib/Target/PowerPC/PPCCallingConv.td#L322) and [GCC](https://github.com/gcc-mirror/gcc/blob/a9173a50e7e346a218323916e4d3add8552529ae/gcc/config/rs6000/rs6000.h#L859).

Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335. This basically does a similar thing I did in rust-lang/rust#130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le. - This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`. - `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR. - See rust-lang/rust#131551 (which is based on this PR) for a PR to implement this. - (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.) Refs: - PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf) - PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL) - PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/) - AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming) - Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189 If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`: - The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile). - As for GPR, only the registers we are treating as reserved are slightly different - r0, r3-r12 are volatile - r1(sp, reserved), r14-31 are nonvolatile - r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs) - r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX) - As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2. - As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](rust-lang/rust#131341 (comment))) in AIX: > When the default Vector enabled mode is used, these registers are reserved and must not be used. > In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls I left [FIXME comment about PPC32 SysV](rust-lang/rust#131341 (comment)) and added ABI check for AIX. - As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX - As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved. We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.) Replaces #111335 and #124279 cc `@ecnelises` `@bzEq` `@lu-zero` r? `@Amanieu` `@rustbot` label +O-PowerPC +A-inline-assembly [^r13]: callee-saved, according to [LLVM](https://github.com/llvm/llvm-project/blob/6a6af0246bd2d68291582e9aefc0543e5c6102fe/llvm/lib/Target/PowerPC/PPCCallingConv.td#L322) and [GCC](https://github.com/gcc-mirror/gcc/blob/a9173a50e7e346a218323916e4d3add8552529ae/gcc/config/rs6000/rs6000.h#L859).

…nieu Stabilize s390x inline assembly This stabilizes inline assembly for s390x (SystemZ). Corresponding reference PR: rust-lang/reference#1643 --- From the requirements of stabilization mentioned in rust-lang#93335 > Each architecture needs to be reviewed before stabilization: > - It must have clobber_abi. Done in rust-lang#130630. > - It must be possible to clobber every register that is normally clobbered by a function call. Done in the PR that added support for clobber_abi. > - Generally review that the exposed register classes make sense. The followings can be used as input/output: - `reg` (`r[0-10]`, `r[12-14]`): General-purpose register - `reg_addr` (`r[1-10]`, `r[12-14]`): General-purpose register except `r0` which is evaluated as zero in an address context This class is needed because `r0`, which may be allocated when using the `reg` class, cannot be used as a register in certain contexts. This is identical to the `a` constraint in LLVM and GCC. See rust-lang#119431 for details. - `freg` (`f[0-15]`): Floating-point register The followings are clobber-only: - `vreg` (`v[0-31]`): Vector register Technically `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `vector` target feature added is enabled, but `core::arch` has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable. Everything related is unstable, so the fact that this is currently a clobber-only should not be considered a stabilization blocker. (rust-lang#130869 tracks unstable stuff here) - `areg` (`a[2-15]`): Access register All of the above register classes except `reg_addr` are needed for `clobber_abi`. The followings cannot be used as operands for inline asm (see also [getReservedRegs](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp#L258-L282) and [SystemZELFRegisters](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.h#L107-L128) in LLVM): - `r11`: frame pointer - `r15`: stack pointer - `a0`, `a1`: Reserved for system use - `c[0-15]` (control register) Reserved by the kernel Although not listed in the above requirements, `preserves_flags` is implemented in rust-lang#111331. --- cc `@uweigand` r? `@Amanieu` `@rustbot` label +O-SystemZ +A-inline-assembly

…nieu Stabilize s390x inline assembly This stabilizes inline assembly for s390x (SystemZ). Corresponding reference PR: rust-lang/reference#1643 --- From the requirements of stabilization mentioned in rust-lang#93335 > Each architecture needs to be reviewed before stabilization: > - It must have clobber_abi. Done in rust-lang#130630. > - It must be possible to clobber every register that is normally clobbered by a function call. Done in the PR that added support for clobber_abi. > - Generally review that the exposed register classes make sense. The followings can be used as input/output: - `reg` (`r[0-10]`, `r[12-14]`): General-purpose register - `reg_addr` (`r[1-10]`, `r[12-14]`): General-purpose register except `r0` which is evaluated as zero in an address context This class is needed because `r0`, which may be allocated when using the `reg` class, cannot be used as a register in certain contexts. This is identical to the `a` constraint in LLVM and GCC. See rust-lang#119431 for details. - `freg` (`f[0-15]`): Floating-point register The followings are clobber-only: - `vreg` (`v[0-31]`): Vector register Technically `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `vector` target feature added is enabled, but `core::arch` has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable. Everything related is unstable, so the fact that this is currently a clobber-only should not be considered a stabilization blocker. (rust-lang#130869 tracks unstable stuff here) - `areg` (`a[2-15]`): Access register All of the above register classes except `reg_addr` are needed for `clobber_abi`. The followings cannot be used as operands for inline asm (see also [getReservedRegs](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp#L258-L282) and [SystemZELFRegisters](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.h#L107-L128) in LLVM): - `r11`: frame pointer - `r15`: stack pointer - `a0`, `a1`: Reserved for system use - `c[0-15]` (control register) Reserved by the kernel Although not listed in the above requirements, `preserves_flags` is implemented in rust-lang#111331. --- cc ``@uweigand`` r? ``@Amanieu`` ``@rustbot`` label +O-SystemZ +A-inline-assembly

Rollup merge of rust-lang#131258 - taiki-e:s390x-stabilize-asm, r=Amanieu Stabilize s390x inline assembly This stabilizes inline assembly for s390x (SystemZ). Corresponding reference PR: rust-lang/reference#1643 --- From the requirements of stabilization mentioned in rust-lang#93335 > Each architecture needs to be reviewed before stabilization: > - It must have clobber_abi. Done in rust-lang#130630. > - It must be possible to clobber every register that is normally clobbered by a function call. Done in the PR that added support for clobber_abi. > - Generally review that the exposed register classes make sense. The followings can be used as input/output: - `reg` (`r[0-10]`, `r[12-14]`): General-purpose register - `reg_addr` (`r[1-10]`, `r[12-14]`): General-purpose register except `r0` which is evaluated as zero in an address context This class is needed because `r0`, which may be allocated when using the `reg` class, cannot be used as a register in certain contexts. This is identical to the `a` constraint in LLVM and GCC. See rust-lang#119431 for details. - `freg` (`f[0-15]`): Floating-point register The followings are clobber-only: - `vreg` (`v[0-31]`): Vector register Technically `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `vector` target feature added is enabled, but `core::arch` has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable. Everything related is unstable, so the fact that this is currently a clobber-only should not be considered a stabilization blocker. (rust-lang#130869 tracks unstable stuff here) - `areg` (`a[2-15]`): Access register All of the above register classes except `reg_addr` are needed for `clobber_abi`. The followings cannot be used as operands for inline asm (see also [getReservedRegs](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp#L258-L282) and [SystemZELFRegisters](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.h#L107-L128) in LLVM): - `r11`: frame pointer - `r15`: stack pointer - `a0`, `a1`: Reserved for system use - `c[0-15]` (control register) Reserved by the kernel Although not listed in the above requirements, `preserves_flags` is implemented in rust-lang#111331. --- cc ``@uweigand`` r? ``@Amanieu`` ``@rustbot`` label +O-SystemZ +A-inline-assembly

Stabilize s390x inline assembly This stabilizes inline assembly for s390x (SystemZ). Corresponding reference PR: rust-lang/reference#1643 --- From the requirements of stabilization mentioned in rust-lang/rust#93335 > Each architecture needs to be reviewed before stabilization: > - It must have clobber_abi. Done in rust-lang/rust#130630. > - It must be possible to clobber every register that is normally clobbered by a function call. Done in the PR that added support for clobber_abi. > - Generally review that the exposed register classes make sense. The followings can be used as input/output: - `reg` (`r[0-10]`, `r[12-14]`): General-purpose register - `reg_addr` (`r[1-10]`, `r[12-14]`): General-purpose register except `r0` which is evaluated as zero in an address context This class is needed because `r0`, which may be allocated when using the `reg` class, cannot be used as a register in certain contexts. This is identical to the `a` constraint in LLVM and GCC. See rust-lang/rust#119431 for details. - `freg` (`f[0-15]`): Floating-point register The followings are clobber-only: - `vreg` (`v[0-31]`): Vector register Technically `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `vector` target feature added is enabled, but `core::arch` has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable. Everything related is unstable, so the fact that this is currently a clobber-only should not be considered a stabilization blocker. (rust-lang/rust#130869 tracks unstable stuff here) - `areg` (`a[2-15]`): Access register All of the above register classes except `reg_addr` are needed for `clobber_abi`. The followings cannot be used as operands for inline asm (see also [getReservedRegs](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp#L258-L282) and [SystemZELFRegisters](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.h#L107-L128) in LLVM): - `r11`: frame pointer - `r15`: stack pointer - `a0`, `a1`: Reserved for system use - `c[0-15]` (control register) Reserved by the kernel Although not listed in the above requirements, `preserves_flags` is implemented in rust-lang/rust#111331. --- cc ``@uweigand`` r? ``@Amanieu`` ``@rustbot`` label +O-SystemZ +A-inline-assembly

…nieu Stabilize s390x inline assembly This stabilizes inline assembly for s390x (SystemZ). Corresponding reference PR: rust-lang/reference#1643 --- From the requirements of stabilization mentioned in rust-lang#93335 > Each architecture needs to be reviewed before stabilization: > - It must have clobber_abi. Done in rust-lang#130630. > - It must be possible to clobber every register that is normally clobbered by a function call. Done in the PR that added support for clobber_abi. > - Generally review that the exposed register classes make sense. The followings can be used as input/output: - `reg` (`r[0-10]`, `r[12-14]`): General-purpose register - `reg_addr` (`r[1-10]`, `r[12-14]`): General-purpose register except `r0` which is evaluated as zero in an address context This class is needed because `r0`, which may be allocated when using the `reg` class, cannot be used as a register in certain contexts. This is identical to the `a` constraint in LLVM and GCC. See rust-lang#119431 for details. - `freg` (`f[0-15]`): Floating-point register The followings are clobber-only: - `vreg` (`v[0-31]`): Vector register Technically `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `vector` target feature added is enabled, but `core::arch` has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable. Everything related is unstable, so the fact that this is currently a clobber-only should not be considered a stabilization blocker. (rust-lang#130869 tracks unstable stuff here) - `areg` (`a[2-15]`): Access register All of the above register classes except `reg_addr` are needed for `clobber_abi`. The followings cannot be used as operands for inline asm (see also [getReservedRegs](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp#L258-L282) and [SystemZELFRegisters](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.h#L107-L128) in LLVM): - `r11`: frame pointer - `r15`: stack pointer - `a0`, `a1`: Reserved for system use - `c[0-15]` (control register) Reserved by the kernel Although not listed in the above requirements, `preserves_flags` is implemented in rust-lang#111331. --- cc ``@uweigand`` r? ``@Amanieu`` ``@rustbot`` label +O-SystemZ +A-inline-assembly

Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335. This basically does a similar thing I did in rust-lang/rust#130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le. - This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`. - `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR. - See rust-lang/rust#131551 (which is based on this PR) for a PR to implement this. - (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.) Refs: - PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf) - PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL) - PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/) - AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming) - Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189 If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`: - The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile). - As for GPR, only the registers we are treating as reserved are slightly different - r0, r3-r12 are volatile - r1(sp, reserved), r14-31 are nonvolatile - r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs) - r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX) - As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2. - As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](rust-lang/rust#131341 (comment))) in AIX: > When the default Vector enabled mode is used, these registers are reserved and must not be used. > In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls I left [FIXME comment about PPC32 SysV](rust-lang/rust#131341 (comment)) and added ABI check for AIX. - As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX - As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved. We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.) Replaces #111335 and #124279 cc `@ecnelises` `@bzEq` `@lu-zero` r? `@Amanieu` `@rustbot` label +O-PowerPC +A-inline-assembly [^r13]: callee-saved, according to [LLVM](https://github.com/llvm/llvm-project/blob/6a6af0246bd2d68291582e9aefc0543e5c6102fe/llvm/lib/Target/PowerPC/PPCCallingConv.td#L322) and [GCC](https://github.com/gcc-mirror/gcc/blob/a9173a50e7e346a218323916e4d3add8552529ae/gcc/config/rs6000/rs6000.h#L859).

Support clobber_abi and vector/access registers (clobber-only) in s39…

fa125e2

…0x inline assembly

rustbot assigned Amanieu Sep 20, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 20, 2024

rustbot added the O-SystemZ Target: SystemZ processors (s390x) label Sep 20, 2024

taiki-e mentioned this pull request Sep 26, 2024

s390x vector facilities support #130869

Open

11 tasks

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 1, 2024

GuillaumeGomez mentioned this pull request Oct 1, 2024

Rollup of 5 pull requests #131098

Merged

bors closed this in 344b6a1 Oct 1, 2024

bors merged commit 344b6a1 into rust-lang:master Oct 1, 2024
6 checks passed

taiki-e deleted the s390x-clobber-abi branch October 1, 2024 19:29

This was referenced Oct 4, 2024

Stabilize s390x inline assembly #131258

Merged

Support clobber_abi in MSP430 inline assembly #131310

Merged

Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly #131341

Merged

rustbot added the A-inline-assembly Area: Inline assembly (`asm!(…)`) label Oct 13, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly #130630

Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly #130630

taiki-e commented Sep 20, 2024 •

edited

Loading

rustbot commented Sep 20, 2024

uweigand commented Sep 23, 2024

taiki-e commented Sep 26, 2024

uweigand commented Sep 30, 2024

Amanieu commented Oct 1, 2024

bors commented Oct 1, 2024

Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly #130630

Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly #130630

Conversation

taiki-e commented Sep 20, 2024 • edited Loading

rustbot commented Sep 20, 2024

uweigand commented Sep 23, 2024

taiki-e commented Sep 26, 2024

uweigand commented Sep 30, 2024

Amanieu commented Oct 1, 2024

bors commented Oct 1, 2024

taiki-e commented Sep 20, 2024 •

edited

Loading