Missing SIMD shift instructions by non-scalar amounts #1586

Activity

1. sunfishcode

   added

   simd

   on Jun 4, 2026
2. ppenzin commented on Jun 10, 2026

   

   ppenzin

   on Jun 10, 2026

   More actions

   I don't think the use case of shifting lanes of one vector by values of corresponding lanes in another vector came up in prior SIMD discussions. Can you share a bit more about the algorithm you are porting?
3. Vanilagy commented on Jun 10, 2026

   

   Vanilagy

   on Jun 10, 2026

   Last edited by Vanilagy

   Author

   More actions

   @ppenzin I'm working on a WASM ProRes decoder and at the core of it is this function (here written in Zig) that parses an entropy-coded code word:

   inline fn parseCode(word: u64, params: u64) ParsedCode {
       const mp: u64 = params & 0b11;
       const g: u64 = (params >> 2) & 0b111;
       const r: u64 = params >> 5;
   
       const n: u64 = @clz(word);
       const is_big = n > mp;
   
       const base = @as(u64, @min(n, mp + 1)) << @as(u6, @intCast(r));
   
       const bits_big = (n << 1) +% g -% mp;
       const bits_small = n + 1 + r;
       const bits = if (is_big) bits_big else bits_small;
       const sub = @as(u64, 1) << (if (is_big) @intCast(g) else @intCast(r));
       const raw = word >> @as(u6, @intCast(64 - bits));
   
       const result = base +% raw -% sub;
   
       return .{
           .value = result,
           .bits = bits,
       };
   }

   I was vectorizing this parser so that it parses four streams at the same time - possible because the above function is branchless (although it does contain some cmovs). The only non-vectorizable instruction here is clz, but that's fine with me, I can dip out of "vector land" once. But, the rest of the code contains a bunch of shifts by dynamic amounts for each lane because of this. Which unfortunately WASM can't model.
4. ppenzin commented on Jun 10, 2026

   

   ppenzin

   on Jun 10, 2026

   More actions

   You are vectorizing this manually, right?

   For 128 bit SIMD 64 bit chunks might not yield very impressive speed ups, but that I what I guess we have flexible vector proposal for.

   What instructions are you getting on native targets, particularly x86?
5. Vanilagy commented on Jun 10, 2026

   

   Vanilagy

   on Jun 10, 2026

   Author

   More actions

   What do you mean by "manually"? I am writing Zig code that uses @Vector, which LLVM compiles to WASM SIMD instructions. I use 64 bit for the scalar version, but the code technically only needs 32, so I'd use a i32x4 in my use case, or even two i32x4 at the same time. (In Zig I can just specify a @Vector(8, u32) and LLVM deals with it properly, splitting it up). But yes, flexible vectors would of course make this even better.

   I have no compiled it for native targets so I can't say.

   👍React with 👍2Reacted by Petr Penzin and T1ckbase
6. ppenzin commented on Jun 11, 2026

   

   ppenzin

   on Jun 11, 2026

   More actions

   I meant something like intrinsics. Curious how this works in Zig, for example in C-like languages build vector from array accesses.

   The reason I am asking about native platforms is because we had situations where one platform has some weird corner case preventing instruction lowering.
7. Vanilagy commented on Jun 11, 2026

   

   Vanilagy

   on Jun 11, 2026

   Author

   More actions

   Zig has one of these "higher-level" SIMD implementations where you completely avoid intrinsics and operate on abstract "Vectors" that the backend then compiles to the correct instructions. Vectors can have arbitrary length (well, up to like 2^32-1).

   So, a lane-wise shift is roughly written as:

   const a: @Vector(4, u32) = ...;
   const b: @Vector(4, u32) = ...;
   const result = a << b;

   Shift by scalar would be:

   const a: @Vector(4, u32) = ...;
   const result = a << @splat(7);