-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly #131341
base: master
Are you sure you want to change the base?
Conversation
Some changes occurred in compiler/rustc_codegen_gcc |
This comment has been minimized.
This comment has been minimized.
76500b8
to
fc3dc84
Compare
|
||
// v0-v19 | ||
// FIXME: PPC32 SysV ABI does not mention vector registers processing. | ||
// https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf | ||
v0, v1, v2, v3, v4, v5, v6, v7, | ||
v8, v9, v10, v11, v12, v13, v14, | ||
v15, v16, v17, v18, v19, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I did not treat these as clobbered only on PPC64 is that the PPC32 ABI document I referenced was released at a time when Altivec/VMX did not exist, and I thought it might not reflect the final status of the PPC32 ABI.
In a similar case, the early ABI documents for s390x (e.g., the one mentioned here) do not mention vector registers, but the ABI documents since the addition of vector facility mention them and all are treated as volatile.
// FIXME: In AIX, v20-v31 are reserved or nonvolatile depending on the mode. | ||
// https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ecnelises @bzEq: Is the default in Rust the default Vector enabled mode, as the name implies? Also, is there a way provided for the compiler to understand the current mode?
(If the first is yes and the second is no, it would be sufficient to simply reject the use of v20-v31 as reserved. If the first is no, this code is fine as is.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should refer to vec-extabi
, which is the default. See
abi: "vec-extabi".into(), |
Opened #131551 (which is based on this 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.) |
9fbedcb
to
bad0db8
Compare
In fact, |
7eee8ce
to
369edf1
Compare
Updated to check ABI in v20-v31 for AIX, and update def_regs to reflect the fact that r13 is not reserved on 32-bit AIX (see also LLVM's getReservedRegs). (32-bit AIX is currently not supported by rustc, although) |
369edf1
to
f3a4182
Compare
f3a4182
to
d30a53e
Compare
This supports
clobber_abi
which is one of the requirements of stabilization mentioned in #93335.This basically does a similar thing I did in #130630 to implement
clobber_abi
for s390x, but for powerpc/powerpc64/powerpc64le.vreg
) as clobber-only, which need to support clobbering of them to implementclobber_abi
.vreg
should be able to accept#[repr(simd)]
types as input/output if the unstablealtivec
target feature is enabled, butcore::arch::{powerpc,powerpc64}
vector types,#[repr(simd)]
, andcore::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.Refs:
If I understand the above four ABI documentations correctly, except for the 32-bit 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
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) in AIX:
I left FIXME comment about PPC32 SysV 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 thanclobber_abi
if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.)Replaces #111335 (closed) and #124279 (draft, no update for about 5 months at the time this PR was created), Closes #124279
cc @ecnelises @bzEq @lu-zero
r? @Amanieu
@rustbot label +O-PowerPC
Footnotes
callee-saved, according to LLVM and GCC. ↩