Open msiglreith opened 5 years ago
Using a macro as a way to re-wrap the call isn't so bad. You (probably) end up with macro code that looks like this.
It does hurt composeability somewhat, but also composeability is hurt just by the argument needing to be a constant. On some level, someone will need to see "hey this value here is totally weird and not like a normal value because of how it's eventually used".
Having a macro invocation is one way to achieve that, but macros don't have the ability to be scoped to a type like a method so it's not perfect.
@Lokathor I tried and it just makes the API so inconsistent and the lack of writing functions on top of it beside using again a macro (which only operate on untyped AST level!) is an additional downside. Currently I just went back to calling the intrinsics directly but I feel it could be done more elegantly.
Some more discussion on this topic happened in https://internals.rust-lang.org/t/pre-rfc-const-function-arguments/6709 It appears to require const generics beforehand, but the syntax is still open for discussions.
Having to propagate the const-ness outward will happen with macro form or with const generics form. That's just always a problem you have to deal with.
Macros being untyped is slightly a problem, but if you look at the macro linked you'll notice that there is still type checking happening everywhere inside of it.
I'm not saying that we don't ever need this fix, just that I think that the work-around we can use in code today is not so debilitating.
Description
SIMD instructions may have arguments which need to be constant at compile time usually indicated by the naming scheme (e.g
imm8
). An example would be_mm_blend_ps
.Issue
Rust currently provides no feature to mark arguments as constant (beside a rustc internal attribute). Libraries like
stdarch
fallback toconstify!
macro which expands all possible constant values (e.g 0-255) into a huge match expr which will call the corresponding instrinsic. This relays on the optimizer and further increases build times. It appears to be not feasible at all for larger immeditate constant types.There appears to be no currently active RFC or further work on this topic: https://github.com/rust-lang/rust/issues/47980
Relevancy for gamedev
At the moment it's difficult to expose these instrincs in any sort of library beside re-exporting the core instrincs themselves. Per-se this is a quite nieche feature but nonetheless should get some attention considering gamedev tends to be quite reliant on SIMD instructions.
For example defining a newtype
pub struct f32x4(__m128)
and trying to implement afn blend(self, rhs: Self, pattern: i32) { _mm_blend_ps(self.0, rhs.0, imm); }
function for it is currently not possible without falling back to the constify workaround. playground