rust (original) (raw)

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

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.

O-PowerPC

Target: PowerPC processors

labels

Oct 11, 2024

This was referenced

Oct 11, 2024

taiki-e changed the title~~Support input/output #[repr(simd)] types in PowerPC inline assembly~~ Support #[repr(simd)] types in input/output of PowerPC inline assembly

Oct 11, 2024

Comment on lines 53 to 57

tgross35 added a commit to tgross35/rust that referenced this pull request

Nov 5, 2024

…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
PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in 64-bit PowerPC ELF Application Binary Interface Supplement
PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in 64-Bit ELF V2 ABI Specification
AIX: Register usage and conventions, Special registers in the PowerPC®, 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, 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 and GCC.

bors added a commit to rust-lang-ci/rust that referenced this pull request

Nov 5, 2024

…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
PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in 64-bit PowerPC ELF Application Binary Interface Supplement
PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in 64-Bit ELF V2 ABI Specification
AIX: Register usage and conventions, Special registers in the PowerPC®, 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

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, 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

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 and GCC.

taiki-e marked this pull request as ready for review

November 5, 2024 12:35

Amanieu added S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Nov 28, 2024

lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request

Nov 28, 2024

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
PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in 64-bit PowerPC ELF Application Binary Interface Supplement
PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in 64-Bit ELF V2 ABI Specification
AIX: Register usage and conventions, Special registers in the PowerPC®, 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

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, 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

Replaces #111335 and #124279

cc @ecnelises @bzEq @lu-zero

r? @Amanieu

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

[^r13]: callee-saved, according to LLVM and GCC.

taiki-e changed the title~~Support #[repr(simd)] types in input/output of PowerPC inline assembly~~ Support input/output in vector registers of PowerPC inline assembly

Nov 28, 2024

rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

and removed S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Nov 28, 2024

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

Nov 29, 2024

bors added a commit to rust-lang-ci/rust that referenced this pull request

Nov 30, 2024

Rollup of 6 pull requests

Successful merges:

rust-lang#131551 (Support input/output in vector registers of PowerPC inline assembly)
rust-lang#132515 (Fix and undeprecate home_dir())
rust-lang#132721 (CI: split x86_64-mingw job)
rust-lang#133106 (changes old intrinsic declaration to new declaration)
rust-lang#133496 (thread::available_parallelism for wasm32-wasip1-threads)
rust-lang#133548 (Add BTreeSet entry APIs to match HashSet)

r? @ghost @rustbot modify labels: rollup

bors added a commit to rust-lang-ci/rust that referenced this pull request

Nov 30, 2024

Rollup of 6 pull requests

Successful merges:

rust-lang#131551 (Support input/output in vector registers of PowerPC inline assembly)
rust-lang#132515 (Fix and undeprecate home_dir())
rust-lang#132721 (CI: split x86_64-mingw job)
rust-lang#133106 (changes old intrinsic declaration to new declaration)
rust-lang#133496 (thread::available_parallelism for wasm32-wasip1-threads)
rust-lang#133548 (Add BTreeSet entry APIs to match HashSet)

r? @ghost @rustbot modify labels: rollup

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Nov 30, 2024

Rollup merge of rust-lang#131551 - taiki-e:ppc-asm-vreg-inout, r=Amanieu

Support input/output in vector registers of PowerPC inline assembly

This extends currently clobber-only vector registers (vreg) support to allow passing #[repr(simd)] types as input/output.

Architecture	Register class	Target feature	Allowed types
PowerPC	`vreg`	`altivec`	`i8x16`, `i16x8`, `i32x4`, `f32x4`
PowerPC	`vreg`	`vsx`	`f32`, `f64`, `i64x2`, `f64x2`

In addition to floats and core::simd types listed above, core::arch types and custom #[repr(simd)] types of the same size and type are also allowed. All allowed types and relevant target features are currently unstable.

r? @Amanieu

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

taiki-e deleted the ppc-asm-vreg-inout branch

December 1, 2024 02:11

antoyo pushed a commit to rust-lang/rustc_codegen_gcc that referenced this pull request

Dec 11, 2024

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
PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in 64-bit PowerPC ELF Application Binary Interface Supplement
PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in 64-Bit ELF V2 ABI Specification
AIX: Register usage and conventions, Special registers in the PowerPC®, 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

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, 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

Replaces #111335 and #124279

cc @ecnelises @bzEq @lu-zero

r? @Amanieu

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

[^r13]: callee-saved, according to LLVM and GCC.

github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this pull request

Mar 11, 2025

Rollup of 6 pull requests

Successful merges:

rust-lang#131551 (Support input/output in vector registers of PowerPC inline assembly)
rust-lang#132515 (Fix and undeprecate home_dir())
rust-lang#132721 (CI: split x86_64-mingw job)
rust-lang#133106 (changes old intrinsic declaration to new declaration)
rust-lang#133496 (thread::available_parallelism for wasm32-wasip1-threads)
rust-lang#133548 (Add BTreeSet entry APIs to match HashSet)

r? @ghost @rustbot modify labels: rollup