Skip to content

When should cfg(target_feature = "backchain") (s390x target feature) be enabled? #142412

Closed

Description

@RalfJung

#127506 added support for the "backchain" target feature, but doing so required adding some hacks to the compiler. Usually, we compute cfg(target_feature) by asking the codegen backend, but apparently that is not possible here. Those hacks already were partially fixed in #129940, but looking at them again I think the logic is still wrong: the logic here

// skip checking special features, as LLVM may not understand them
if RUSTC_SPECIAL_FEATURES.contains(feature) {
return true;
}

will conclude that the target feature is always enabled in the base target! So if someone adds a s390x target where backchain is disabled by default, we'll falsely claim that it is enabled. And right now, without a -Ctarget-feature argument, we'll say the feature is enabled. I have no clue if that makes sense, but it's definitely not future-proof. (Or even worse, if a different architecture also starts using this feature name, we'll conclude the feature is enabled.)

I think RUSTC_SPECIAL_FEATURES needs to be removed and redeveloped from scratch, the current design makes little sense. (It is also extremely easy to be confused with the very different RUSTC_SPECIFIC_FEATURES hack.)

Is this hack even still needed? There were some comments indicating that this hack exists to deal with LLVM 18 and older, which we do not support any more.

Cc @liushuyu @uweigand @cuviper

Activity

  1. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Jun 12, 2025
  2. uweigand commented on Jun 14, 2025

    @uweigand
    Contributor

    And right now, without a -Ctarget-feature argument, we'll say the feature is enabled.

    Well, this is definitely wrong - the feature is disabled by default in LLVM. You only get the backchain when explicitly asking for it.

    Is this hack even still needed? There were some comments indicating that this hack exists to deal with LLVM 18 and older, which we do not support any more.

    Yes, as of LLVM 18 backchain is handled as a normal target feature in the LLVM back-end, so I don't think this hack is needed any more.

  3. RalfJung commented on Jun 14, 2025

    @RalfJung
    MemberAuthor

    Yes, as of LLVM 18 backchain is handled as a normal target feature in the LLVM back-end, so I don't think this hack is needed any more.

    Great. I have a local patch that should clean this up, but it is waiting for #140920 to land.

  4. RalfJung commented on Jun 14, 2025

    @RalfJung
    MemberAuthor

    Is it still also necessary to set the backchain attribute on each function, or does enabling the LLVM target feature suffice?

  5. uweigand commented on Jun 14, 2025

    @uweigand
    Contributor

    Is it still also necessary to set the backchain attribute on each function, or does enabling the LLVM target feature suffice?

    The only thing the backchain attribute still does is to build the function using a subtarget with the target feature enabled. So if you're already setting the target feature, the attribute doesn't do anything.

  6. RalfJung commented on Jun 15, 2025

    @RalfJung
    MemberAuthor

    Okay, thanks. Would be good if someone could submit a PR to clean that up, then.

  7. added 2 commits that reference this issue on Jun 20, 2025
  8. added a commit that references this issue on Jun 20, 2025
  9. removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Jun 20, 2025
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

    C-bugCategory: This is a bug.O-SystemZTarget: SystemZ processors (s390x)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions