Skip to content

How should cfg(target-feature) behave around forbidden target features? #132351

Closed
@RalfJung

Description

@RalfJung

See #129884 and #116344 for context explaining what a forbidden target feature is.

The plan for target features like fpreg on ARM is that they will be forbidden unless the target has soft-float in its base feature set. This means our hardfloat ARM targets require fpregs, but on our softfloat ARM targets users can opt-in to having the FPU avialable, it just won't be used for the ABI. See #124404 for why we can't just forbid fpregs outright.

What should the behavior of cfg(target-feature = "fpregs") be, then? For now, #129884 makes it so that forbidden features are never set in cfg. But for this one it seems like when we unstable add fpregs for softfloat targets, then we'll want to unstably expose the ability to do cfg(target-feature = "fpregs") on all ARM targets. So we'll need a concept of target features that are forbidden to set, but can be unstably (and eventually, stably) queried. At the same time, other target features like soft-float likely should never be queried.

So seems like for these more complicated features, the question whether a feature is forbidden to set is somewhat orthogonal to its stability. I have some plans for a follow-up PR to #129884 to be able to represent that, but still need to figure out the details.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-ABIArea: Concerning the application binary interface (ABI)A-target-featureArea: Enabling/disabling target features like AVX, Neon, etc.C-discussionCategory: Discussion or questions that doesn't represent real issues.E-needs-designThis issue needs exploration and design to see how and if we can fix/implement itT-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