Skip to content

Tracking Issue for powerpc_target_feature #150255

Open

Description

@RalfJung

View all comments

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

Activity

  1. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Dec 22, 2025
  2. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    A-target-featureArea: Enabling/disabling target features like AVX, Neon, etc.
    O-PowerPCTarget: PowerPC processors
    on Dec 22, 2025
  3. added a commit that references this issue on Jan 1, 2026
  4. added a commit that references this issue on Jan 1, 2026
  5. tgross35 commented on Oct 9, 2026

    @tgross35
    Member

    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?

  6. tgross35 commented on Oct 9, 2026

    @tgross35
    Member

    See also #111191 for the macros

  7. taiki-e commented on Oct 9, 2026

    @taiki-e
    Member

    What are msync and partword-atomics?

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

  8. taiki-e commented on Oct 9, 2026

    @taiki-e
    Member

    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.

  9. tgross35 commented on Oct 9, 2026

    @tgross35
    Member

    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
  10. taiki-e commented on Oct 9, 2026

    @taiki-e
    Member

    Does the remaining list seem reasonable then?

    It seems reasonable to me.

  11. RalfJung commented on Oct 9, 2026

    @RalfJung
    MemberAuthor

    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.

  12. RalfJung commented on Oct 9, 2026

    @RalfJung
    MemberAuthor

    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?

  13. pmur commented on Oct 9, 2026

    @pmur
    Contributor

    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?).

  14. 15 remaining items

  15. tgross35 commented on Oct 19, 2026

    @tgross35
    Member

    Sorry, misclicked.

    Transforming that file a bit, the list is:

    (FeatureP8Altivec (FeatureAltivec))
    (FeatureP8Vector (FeatureVSX FeatureP8Altivec))
    (FeatureP9Altivec (FeatureISA3_0, FeatureP8Altivec))
    (FeatureP9Vector (FeatureISA3_0, FeatureP8Vector, FeatureP9Altivec))
    (FeatureP10Vector (FeatureISA3_1, FeatureP9Vector))
    
    ; enabled by target-cpu=pwr8
    (P8Features
      (P8InheritableFeatures
        (P8AdditionalFeatures (FeatureP8Altivec, FeatureP8Vector, FeatureP8Crypto, FeatureISA2_07, ...))))
    
    ; enabled by target-cpu=pwr9
    (P9Features
      (P9InheritableFeatures
        (P8InheritableFeatures
          (P8AdditionalFeatures (FeatureP8Altivec, FeatureP8Vector, FeatureP8Crypto, FeatureISA2_07, ...)))
        (P9AdditionalFeatures (FeatureP9Altivec, FeatureP9Vector, FeatureISA3_0, ...)))
    
    target-cpu=pwr10 adds FeatureISA3_1 and FeatureP10Vector
    

    So as I understand it, the features we have now like power9-vector are already just implying ISA 3.0 with VSX and Altivec. I think it would be fine to replace those.

  16. tgross35 commented on Oct 20, 2026

    @tgross35
    Member

    I think there are some things worth getting agreement on, so opened an MCP for updating the features rust-lang/compiler-team#1046

  17. added 6 commits that reference this issue on Oct 20, 2026
  18. added a commit that references this issue on Oct 21, 2026
  19. added a commit that references this issue on Oct 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-target-featureArea: Enabling/disabling target features like AVX, Neon, etc.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCO-PowerPCTarget: PowerPC processorsT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions