[rust-dev] RFC: Tuple Swizzling/Shuffling

Richard Diamond wichard at vitalitystudios.com
Tue Jan 14 09:33:30 PST 2014


Basically the idea here is to support shuffling for SIMD types in a way
that can be easily lowered to IR (LLVM's shufflevector requires the mask be
a vector of constants, so an intrinsic function is out of the question),
however I image this sugar could extend to tuples with multiple types.

Some examples:

let vec = (1.0f32, 2.0f32, 3.0f32, 4.0f32);
let all_x = vec -> (0, 0, 0, 0); // perhaps this should be "vec <- (0, 0,
0, 0)"?
assert_eq!(all_x, (1.0f32, 1.0f32, 1.0f32, 1.0f32));
let single_x = vec -> (0);
assert_eq!(single_x, (1.0f32));

let mut vec = vec;
vec <- (0) = 5.0f32; // set x only
vec <- (1, 2) = (6.0f32, 7.0f32) // set y & z
assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32));

let vec = vec;
// the mask may be arbitrarily long:
assert_eq!(vec -> (0, 1, 2, 3, 0), (5.0f32, 6.0f32, 7.0f32, 4.0f32,
5.0f32));

// leaves vec unchanged
let functional_update = vec -> (0, 1, 3) .. (0.5f32, 1.0f32, 10.0f32);
// functional_update would take it's type from vec
assert_eq!(vec, (5.0f32, 6.0f32, 7.0f32, 4.0f32));
assert_eq!(functional_update, (0.5f32, 1.0f32, 7.0f32, 10.0f32));

A couple of things would need to be disallowed, however:

let mut vec = vec;
// no duplicate assignments/functional updates:
vec <- (0, 0) = (..);
let _ = vec -> (0, 1, 2, 3, 0) .. (..);
// no out-of-bounds:
vec <- (5, 9000) = (..);
let _ = vec -> (5, 9001);
let _ = vec -> (5, 9002) .. (..);
let _ = vec -> (0, 1, 2, 3, 4) .. (..);
// all mask values must be a const expr:
let mut non_const_expr = 15;
vec <- (non_const_expr) = (..);
let _ = vec -> (non_const_expr) .. (..);
let _ = vec -> (non_const_expr);
// mismatched tuple sizes:
vec <- (0, 1) = (0.0f32, 0.0f32, 0.0f32);
let _ = vec -> (0) .. (0.0f32, 0.0f32);

AIUI, the notation would be:
tuple_mask : '(' integer [ ',' integer ] * ')' ;
tuple_expr : '(' expr [ ',' expr ] * ')' |
                  tuple_expr "->" tuple_mask [ ".." tuple_expr ] ? ;

I'm willing to write this myself, but I'd like some consensus/feedback
regarding ze proposed sugar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/c1dd988f/attachment.html>


More information about the Rust-dev mailing list