retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features #135927

azhogin · 2025-01-23T10:46:14Z

-Zretpoline and -Zretpoline-external-thunk flags are target modifiers (tracked to be equal in linked crates).

Enables target features for -Zretpoline-external-thunk:
+retpoline-external-thunk, +retpoline-indirect-branches, +retpoline-indirect-calls.
Enables target features for -Zretpoline:
+retpoline-indirect-branches, +retpoline-indirect-calls.

It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.

Also this PR forbids to specify those target features manually (warning).

rustbot · 2025-01-23T10:46:22Z

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-01-23T10:46:25Z

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

compiler-errors · 2025-01-23T18:12:36Z

r? compiler

chenyukang · 2025-02-05T02:30:16Z

r? compiler

fee1-dead · 2025-02-08T01:29:07Z

r? compiler

lcnr · 2025-02-09T18:12:07Z

r? @davidtwco maybe 😅

azhogin · 2025-06-08T21:51:23Z

@rustbot ready

…o enable retpoline-related target features

davidtwco · 2025-06-12T09:47:51Z

@bors r+

bors · 2025-06-12T09:47:54Z

📌 Commit 5601490 has been approved by davidtwco

It is now in the queue for this repository.

Rollup of 9 pull requests Successful merges: - #128425 (Make `missing_fragment_specifier` an unconditional error) - #135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features) - #140770 (add `extern "custom"` functions) - #142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches) - #142248 (Add supported asm types for LoongArch32) - #142267 (assert more in release in `rustc_ast_lowering`) - #142274 (Update the stdarch submodule) - #142276 (Update dependencies in `library/Cargo.lock`) - #142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library) Failed merges: - #140920 (Extract some shared code from codegen backend target feature handling) r? `@ghost` `@rustbot` modify labels: rollup try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-gnu try-job: dist-i586-gnu-i586-i686-musl try-job: test-various

Rollup merge of #135927 - azhogin:azhogin/retpoline, r=davidtwco retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features `-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates). * Enables target features for `-Zretpoline-external-thunk`: `+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`. * Enables target features for `-Zretpoline`: `+retpoline-indirect-branches`, `+retpoline-indirect-calls`. It corresponds to clang -mretpoline & -mretpoline-external-thunk flags. Also this PR forbids to specify those target features manually (warning). Issue: #116852

RalfJung · 2025-06-13T21:50:53Z

compiler/rustc_session/src/errors.rs

As discussed in #140920, codegen_ssa is probably a much better place for this target feature handling.

RalfJung · 2025-06-13T21:53:25Z

compiler/rustc_target/src/target_features.rs

@@ -34,6 +34,9 @@ pub enum Stability {
    /// particular for features are actually ABI configuration flags (not all targets are as nice as
    /// RISC-V and have an explicit way to set the ABI separate from target features).
    Forbidden { reason: &'static str },
+    /// This feature can not be set via `-Ctarget-feature` or `#[target_feature]`, it can only be set
+    /// by target modifier flag. Target modifier flags are tracked to be consistent in linked modules.
+    TargetModifierOnly { reason: &'static str, flag: &'static str },


Why are such features even listed here? The entire point of this file is to define the Rust feature names used for -Ctarget-feature and #[target_feature] and cfg(target_feature). Mixing in other things here seems like a big mess...

RalfJung · 2025-06-13T21:56:30Z

compiler/rustc_session/src/features.rs

+            Stability::TargetModifierOnly { reason, flag } => {
+                if !sess.opts.target_feature_flag_enabled(*flag) { Err(reason) } else { Ok(()) }
+            }


I don't understand this logic. Somewhere it says these target features are not allowed in -Ctarget-features, but now here it seems to allow them... sometimes?

Oh, you are taking the named -Z options and mixing them with the -Ctarget-features flag. Then of course things become messy and they have to masquerade as actual target features in parts of the compiler even though they aren't, actually, target features for us.

I think it's a bad idea to ever mix these. The code paths should be entirely separate all the way until actually generating backend target features. Please let's not make the target feature code even more spaghetti than it already was.

If I understand this PR correctly, then once I set -Zretpoline-external-thunk this would actually let me set -Ctarget-features=-retpoline-external-thunk without any warning. My refactor in #140920 fixes that.

RalfJung · 2025-06-13T22:11:30Z

compiler/rustc_codegen_llvm/src/llvm_util.rs

@@ -707,6 +707,12 @@ pub(crate) fn target_cpu(sess: &Session) -> &str {
    handle_native(cpu_name)
 }

+fn llvm_features_by_flags(sess: &Session) -> Vec<&str> {


The handling for fixed_x18 should probably be merged with this. (That would also have been an easier model to follow for adding the new flags.)

RalfJung · 2025-06-13T22:18:27Z

#140920 now also changes the logic for these new flags quite a bit, in an attempt to reduce the spaghetti. Might be worth taking a look.

RalfJung · 2025-06-13T22:28:45Z

compiler/rustc_target/src/target_features.rs

@@ -49,6 +52,7 @@ impl<CTX> HashStable<CTX> for Stability {
            Stability::Forbidden { reason } => {
                reason.hash_stable(hcx, hasher);
            }
+            Stability::TargetModifierOnly { .. } => {}


Not hashing the fields here is sus... but I'm anyway going to entirely remove this variant in my PR.

RalfJung · 2025-06-13T22:36:17Z

tests/ui/check-cfg/target_feature.stderr

Is it deliberate that these are added to the list of possible values for cfg(target_feature)? They are not set via -Ctarget-feature, so that seems confusing. Also, I can't find any logic here that would actually ever make cfg!(target_feature="retpoline-external-thunk") be "true", and no test checking that it would ever be "true". This seems like an accidental side-effect of adding a new target_features::Stability variant?

I think this is being set as a target feature "because LLVM treats it as a target feature". There was no discussion of exposing this to the language that I remember.

rustbot assigned compiler-errors Jan 23, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jan 23, 2025

azhogin force-pushed the azhogin/retpoline branch from e808e83 to 12b286f Compare January 23, 2025 10:48