SIMD in `const` easily

language design
22

Again, it's implemented in a crate which is external to the compiler / standard library (std_detect).

I guess what you're suggesting is vendoring it all into std first, then doing that?

23

It already is provided by std. All std needs to do is wrap it in its own macro that passes the arguments through using const_eval_select.

1 Like
24

Can you give a complete example of how you'd think it would work, also illustrating how it would handle calling the const fn path as a fallback?

Part of what makes the design of const_eval_select difficult is you can't easily shove it into an if statement, which is how is_*_feature_detected! is typically used, with the fallback being an else.

It's also resisted various attempts by people to put a macro-based facade on it.

25

I believe what you're thinking is that std would do something like:

macro_rules! is_x86_feature_detected {
    ($feat:tt) => {
        $crate::intrinsics::const_eval_select(
            (),
            || false,
            || $crate::std_detect::is_x86_feature_detected!($feat),
        )
    }
}

The issue with stabilizing this is the exact same as with const_eval_select, emphasis mine:

Rust has not yet decided that const fn are allowed to tell whether they run at compile-time or at runtime. Therefore, when using this intrinsic anywhere that can be reached from stable, it is crucial that the end-to-end behavior of the stable const fn is the same for both modes of execution.

In fact, I would nearly be able to write const fn is_const_eval as is_x86_feature_detected!("sse").

Quoting from pointer::guaranteed_eq, another instance of compile time behavior difference, emphasis mine:

The return value may change [...] depending on the compiler version and unsafe code must not rely on the result of this function for soundness. It is suggested to only use this function for performance optimizations where [the conservative const results] do not affect the outcome, but just the performance. The consequences of using this method to make runtime and compile-time code behave differently have not been explored. This method should not be used to introduce such differences, and it should also not be stabilized before we have a better understanding of this issue.

Calling intrinsics that are only sound if the target feature exists at runtime sure sounds like relying on the result of is_x86_feature_detected! to me.

1 Like
26

Thinking about this, I guess you're right that is_x86_feature_detected!("sse") is for all intents and purposes is_const_eval. So it looks like we need to solve that first.

1 Like