You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
When should cfg(target_feature = "backchain") (s390x target feature) be enabled? #142412
#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
ifRUSTC_SPECIAL_FEATURES.contains(feature){
returntrue;
}
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.
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.
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.
Activity
uweigand commentedon Jun 14, 2025
Well, this is definitely wrong - the feature is disabled by default in LLVM. You only get the backchain when explicitly asking for it.
Yes, as of LLVM 18
backchainis handled as a normal target feature in the LLVM back-end, so I don't think this hack is needed any more.RalfJung commentedon Jun 14, 2025
Great. I have a local patch that should clean this up, but it is waiting for #140920 to land.
RalfJung commentedon Jun 14, 2025
Is it still also necessary to set the backchain attribute on each function, or does enabling the LLVM target feature suffice?
uweigand commentedon Jun 14, 2025
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.
RalfJung commentedon Jun 15, 2025
Okay, thanks. Would be good if someone could submit a PR to clean that up, then.
Rollup merge of rust-lang#140920 - RalfJung:target-feature-unificatio…
Rollup merge of rust-lang#140920 - RalfJung:target-feature-unificatio…
Unrolled build for #140920