Tracking Issue for powerpc_target_feature

This is a tracking issue for powerpc_target_feature, guarding target features on powerpc.
This is a catch-all issue for all target features on that target. See this file for a list of target features currently guarded by this feature gate.

See #44839 for discussion from before this feature got its own tracking issue.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

Figure out ABI interactions and other possible blockers/concerns
Move target features that should not be part of the initial stabilization under separate feature gates
Final Comment Period (FCP)
Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

none at the moment

Implementation history

Rollup merge of rust-lang#150264 - RalfJung:target-feature-tracking-s…

Unrolled build for #150264

@Gelbpunkt

I think it may be possible to stabilize the features that aren't internal-only. Currently we have:

    ("altivec", Unstable(sym::powerpc_target_feature), &[]),
    (
        "hard-float",
        // Pinned down by [`Target::abi_required_features`].
        InternalOnly { reason: "unsupported ABI-configuration feature", hard_error: false },
        &[],
    ),
    ("msync", Unstable(sym::powerpc_target_feature), &[]),
    ("partword-atomics", Unstable(sym::powerpc_target_feature), &[]),
    ("power8-altivec", Unstable(sym::powerpc_target_feature), &["altivec"]),
    ("power8-crypto", Unstable(sym::powerpc_target_feature), &["power8-altivec"]),
    ("power8-vector", Unstable(sym::powerpc_target_feature), &["vsx", "power8-altivec"]),
    ("power9-altivec", Unstable(sym::powerpc_target_feature), &["power8-altivec"]),
    ("power9-vector", Unstable(sym::powerpc_target_feature), &["power8-vector", "power9-altivec"]),
    ("power10-vector", Unstable(sym::powerpc_target_feature), &["power9-vector"]),
    ("quadword-atomics", Unstable(sym::powerpc_target_feature), &[]),
    (
        "spe",
        // Pinned down by [`Target::abi_required_features`].
        InternalOnly { reason: "unsupported ABI-configuration feature", hard_error: false },
        &[],
    ),
    ("vsx", Unstable(sym::powerpc_target_feature), &["altivec"]),

That hierarchy seems pretty reasonable, but some notes:

These names use "powerN" while we call the CPU -Ctarget-cpu=pwrN. I think "powerN" is fine since it matches the C defines like __POWER9_VECTOR__
GCC calls quadword-atomics quad-memory-atomic/__QUAD_MEMORY_ATOMIC__
What are msync and partword-atomics?

(Referencing https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html and https://gcc.godbolt.org/z/rz9oTG99b for GCC)

@Gelbpunkt @pmur @daltenty any thoughts?

See also #111191 for the macros

What are msync and partword-atomics?

See #130873 (partword-atomics/quadword-atomics) and #137860 (msync).

msync (which indicates that lwsync (sync 1) is not available) is a feature in the same category as RISC-V e, so I think it should probably be discussed separately from the others.

Does the remaining list seem reasonable then?

altivec
vsx
partword-atomics
quadword-atomics
power8-altivec
power8-crypto
power8-vector
power9-altivec
power9-vector
power10-vector

Does the remaining list seem reasonable then?

It seems reasonable to me.

Do any of these have ABI effects, other than availability of vector registers as reflected in POWERPC_FEATURES_FOR_CORRECT_FIXED_LENGTH_VECTOR_ABI?

const POWERPC_FEATURES_FOR_CORRECT_FIXED_LENGTH_VECTOR_ABI: &'static [(u64, &'static str)] =
    &[(128, "altivec")];

This means: SIMD vectors up to 128 bit are allowed in extern "C" when "altivec" is enabled.

For these "atomic" target features, what effect do they have? If some part of the code has those features and some part does not, and they share access to the same &Atomic*, will they use different instructions? Will they still interoperate correctly?

What is the reason for keeping -vector and/or -altivec on the powerx targets? I would think only powerx is needed for 8/9/10 these days, with implied vsx/altivec/crypto support.

I also suspect the power8-crypto feature should be implied by any newer powerx cpu (did I misread the source?).

Do any of these have ABI effects, other than availability of vector registers as reflected in POWERPC_FEATURES_FOR_CORRECT_FIXED_LENGTH_VECTOR_ABI?

As for vector types, PowerPC's vector registers are always 128-bit, so that list should be sufficient. Also, all vector types on PowerPC are unstable (core::arch::powerpc::* and core::simd::*).

However, if this comment from over 10 years ago is still true (at first glance, this seems still true), then since we don't properly support passing vector arguments to extern "C" functions in the first place, we should make that list empty for now...

rust/compiler/rustc_target/src/callconv/powerpc64.rs

Lines 1 to 3 in 76c9095

    
           // FIXME: 
        
           // Alignment of 128 bit types is not currently handled, this will 
        
           // need to be fixed when PowerPC vector support is added.

As for non-vector types, at least in the ELFv2 ABI, IEEE f128 (f128) is also passed via vector registers (refs: 64-Bit ELF V2 ABI Specification Revision 1.5, Section 2.2.4), so we need to check not only vector types but also f128 (I don't know if this ABI check has been implemented). That said, since f128 is unstable and target_has_reliable_f128 cfg is not set for any PowerPC targets, I don't think it should be a blocker here.

For these "atomic" target features, what effect do they have? If some part of the code has those features and some part does not, and they share access to the same &Atomic*, will they use different instructions? Will they still interoperate correctly?

AFAIK, there are no interoperability issues.

If partword-atomics (8-bit and 16-bit LL/SC) is enabled LLVM uses it to implement 8-bit and 16-bit atomics, otherwise uses 32-bit LL/SC to implement 8-bit and 16-bit atomics. Both are lock-free.¹
If quadword-atomics (128-bit LL/SC) is enabled LLVM uses it to implement 128-bit atomics, otherwise Rust cannot provide 128-bit atomics because there is no another way to implement (lock-free) 128-bit atomics.

In PowerPC's hardware memory model, mixed-size atomic accesses are fine, just as 32-bit LL/SC-based 8-bit atomics (which may be invoked concurrently with 8-bit store instructions) already rely on them. ↩

so we need to check not only vector types but also f128

Having this check works for vector types but not for other types. Those need a lot more work.
For instance, what about f128 passed via the "Rust" ABI? That must always be supported, so we cannot make it depend on "altivec". We have to have a consistent ABI that's the same no matter what -Ctarget-features says. (It can be different between different target triples though.)

But yeah that's more of a blocker for f128, not for these target features. powerpc is already listed on #138616. Though there, "vsx" is mentioned rather than "altivec"?

If quadword-atomics (128-bit LL/SC) is enabled LLVM uses it to implement 128-bit atomics, otherwise Rust cannot provide 128-bit atomics because there is no another way to implement (lock-free) 128-bit atomics.

So target_has_atomic=128 has to depend on target features? Fun. I have no idea if we get this right. Seems best to not yet stabilize "quadword-atomics" then; 128bit atomics are anyway still unstable.

Though there, "vsx" is mentioned rather than "altivec"?

As far as I can tell from ELFV2 ABI doc, there's nothing to indicate that VSX is required, but since I haven't followed the discussions on GCC or LLVM, it's possible I'm missing something.

Section 2.1.2.2 says "IEEE128 quad-precision values are passed and returned in VMX parameter registers"
Section 2.2.2.1 says "Parameters and function results in IEEE BINARY 128 QUADRUPLE PRECISION format shall be passed in a single 128-bit vector register as if they were vector values"
Section 2.2.4 says:
- "For the purpose of determining a qualified floating-point argument, IEEE BINARY 128 QUADRUPLE PRECISION shall be considered a vector data type. In addition, IEEE BINARY 128 QUADRUPLE PRECISION is like a vector data type for determining if multiple aggregate members are like"
- "Binary extended precision numbers in IEEE BINARY 128 QUADRUPLE PRECISION format (see Section 2.2.2.1, “IEEE BINARY 128 QUADRUPLE PRECISION” [31]) are passed using a VMX register"
- "Up to 12 quad-precision parameters can be passed in v2–v13. For the purpose of determining qualified floating-point and vector arguments, an IEEE 128b type shall be considered a "like" vector type, and a complex _Float128 shall be treated as two individual scalar elements"
Section 2.2.4.1 says:
- "IEEE BINARY 128 QUADRUPLE PRECISION is passed in one VR"
- "Assumes == vr is true for IEEE BINARY 128 QUADRUPLE PRECISION"

If quadword-atomics (128-bit LL/SC) is enabled LLVM uses it to implement 128-bit atomics, otherwise Rust cannot provide 128-bit atomics because there is no another way to implement (lock-free) 128-bit atomics.

So target_has_atomic=128 has to depend on target features? Fun. I have no idea if we get this right. Seems best to not yet stabilize "quadword-atomics" then; 128bit atomics are anyway still unstable.

quadword-atomics is similar to x86_64's cmpxchg16b target feature (stabilized in Rust 1.69). In the current Rust, we can only provide 128-bit atomics in core::sync::atomic if they are enabled in the target spec. There have been proposals to support it based on the target feature, but they have not yet been accepted.

128bit atomics are anyway still unstable.

128-bit atomics in core::sync::atomic is unstable, but it can be used via the inline assembly (stabilized in Rust 1.95).

18. As far as I can tell from ELFV2 ABI doc, there's nothing to indicate that VSX is required, but since I haven't followed the discussions on GCC or LLVM, it's possible I'm missing something.

It's buried in the openpower compliance documents. It has the notion of linux compliance which the hardware implementation must meet. Annoyingly, the link to that document is broken on the website. Minor tangent, float128 is a linux optional feature.

As far as I can tell from ELFV2 ABI doc, there's nothing to indicate that VSX is required, but since I haven't followed the discussions on GCC or LLVM, it's possible I'm missing something.

It's buried in the openpower compliance documents. It has the notion of linux compliance which the hardware implementation must meet. Annoyingly, the link to that document is broken on the website. Minor tangent, float128 is a linux optional feature.

Hmm, I thought linux compliance is about instruction availability (BFP128 is indeed included in Linux Optional Category in PowerISA Version 3.1C Book III Appendix E, and Linux HWCAP2 has PPC_FEATURE2_HAS_IEEE128 separated from PPC_FEATURE2_ARCH_3_00 and PPC_FEATURE_HAS_VSX), not about ABI (calling conversation)...

Mostly, yes. Though, as noted the ABI conflates them for float128 support.

What is the reason for keeping -vector and/or -altivec on the powerx targets? I would think only powerx is needed for 8/9/10 these days, with implied vsx/altivec/crypto support.

I also suspect the power8-crypto feature should be implied by any newer powerx cpu (did I misread the source?).

I think you read that right. We're currently enabling them together

rust/library/std_detect/src/detect/os/linux/powerpc.rs

Lines 23 to 31 in 32dba69

    
           let power8_features = auxv.hwcap2 & 0x80000000 != 0; 
        
           enable_feature(&mut value, Feature::power8, power8_features); 
        
           enable_feature(&mut value, Feature::power8_altivec, power8_features); 
        
           enable_feature(&mut value, Feature::power8_crypto, power8_features); 
        
           enable_feature(&mut value, Feature::power8_vector, power8_features); 
        
           let power9_features = auxv.hwcap2 & 0x00800000 != 0; 
        
           enable_feature(&mut value, Feature::power9, power9_features); 
        
           enable_feature(&mut value, Feature::power9_altivec, power9_features); 
        
           enable_feature(&mut value, Feature::power9_vector, power9_features);

but it looks like hwcap has a separate PPC_FEATURE2_VEC_CRYPTO https://github.com/torvalds/linux/blob/3857c2fe5449541e24afc5efdb0f81a8a8f9a3a0/arch/powerpc/include/uapi/asm/cputable.h#L40-L47. Is it possible to enable/disable crypto in the os, perhaps?

Maybe we should at least drop power*-vector and power*-altivec in favor of separate power*, vsx, and altivec.

However, if this comment from over 10 years ago is still true (at first glance, this seems still true), then since we don't properly support passing vector arguments to extern "C" functions in the first place, we should make that list empty for now...

This only affects core::arch right? I added an unresolved question to #111145.

For f128, there's a bit of parallel discussion at #floating-point > f128 on PowerPC without VSX. I don't think that needs to block anything with these features, though, we just have some work to do figuring out what we can and can't support.

Looks like powerN-* names come from LLVM https://github.com/llvm/llvm-project/blob/6bcb0a8b3d941650fda2157149c96a98b33eec14/llvm/lib/Target/PowerPC/PPC.td#L287-L297

Navigation Menu

Repository navigation

Tracking Issue for powerpc_target_feature #150255

About tracking issues

Steps

Unresolved Questions

Implementation history

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// FIXME:
	// Alignment of 128 bit types is not currently handled, this will
	// need to be fixed when PowerPC vector support is added.

	let power8_features = auxv.hwcap2 & 0x80000000 != 0;
	enable_feature(&mut value, Feature::power8, power8_features);
	enable_feature(&mut value, Feature::power8_altivec, power8_features);
	enable_feature(&mut value, Feature::power8_crypto, power8_features);
	enable_feature(&mut value, Feature::power8_vector, power8_features);
	let power9_features = auxv.hwcap2 & 0x00800000 != 0;
	enable_feature(&mut value, Feature::power9, power9_features);
	enable_feature(&mut value, Feature::power9_altivec, power9_features);
	enable_feature(&mut value, Feature::power9_vector, power9_features);

Tracking Issue for powerpc_target_feature #150255

Description

About tracking issues

Steps

Unresolved Questions

Implementation history

Activity

tgross35 commented on Oct 9, 2026

tgross35 commented on Oct 9, 2026

taiki-e commented on Oct 9, 2026

taiki-e commented on Oct 9, 2026

tgross35 commented on Oct 9, 2026

taiki-e commented on Oct 9, 2026

RalfJung commented on Oct 9, 2026

RalfJung commented on Oct 9, 2026

pmur commented on Oct 9, 2026

taiki-e commented on Oct 9, 2026

Footnotes

RalfJung commented on Oct 9, 2026

taiki-e commented on Oct 9, 2026

pmur commented on Oct 9, 2026

taiki-e commented on Oct 9, 2026

pmur commented on Oct 9, 2026

tgross35 commented on Oct 10, 2026

tgross35 commented on Oct 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions