Caleb Zulawski

In the branch I'm working on, the following is possible: ```rust #[multiversion(targets = "simd", selected_target = "TARGET")] fn foo(x: &mut [f32]) { const WIDTH: usize = TARGET.suggested_simd_width::(); } ``` Thoughts?

A few options/thoughts: - Runtime control over the dispatcher. Just a function that limits/enables specific instruction sets? - Compile time control over the dispatcher. Disables `target_clones` to build with the...

Half of this task is complete with the addition of the `std` option--when disabled, runtime CPU feature detection is replaced with compile-time conditional compilation.

I'm working on a change that should place the clones within the scope of the multiversioned function, which I think should incidentally solve this as well.

More broadly, though, I'm unsure how to handle attributes on the multiversioned function vs on the clones. Copying all attributes doesn't quite make sense, for example: ```rust #[multiversion(...)] #[export_name =...

Interesting problem with the attribute scope. I've had some reservations about the implementation of `#[target_cfg]` (as well as `dispatch!`), since they're not actually real macros. The subset of features problem...

The idea is that the macro produces the constant, not that it's provided by the user. You could use const generics to avoid duplication (though you could also just do...

You wouldn't be able to return a different type with `#[target_cfg]` either, the function must always return the same type.

That's similar to the example I posted above. You would do: ```rust #[multiversion] #[clone(target = "[x86|x86_64]+avx+sse4.1")] #[features = "FEATURES"] fn foo() { const VECTOR_SIZE: usize = vector_size(FEATURES); match VECTOR_SIZE {...

Well, it's still doing the multiversioning for you, giving you a safe abstraction over something that's inherently `unsafe`. I think there is room for a library built on top of...