13

Is there any way to rebuild the _mm_slli_si128 instruction in AVX2 to shift an __mm256i register by x bytes?

The _mm256_slli_si256 seems just to execute two _mm_slli_si128 on a[127:0] and a[255:128].

The left shift should work on a __m256i like this:

[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, ..., 32] -> [2, 3, 4, 5, 6, 7, 8, 9, ..., 0]

I saw in thread that it is possible to create a shift with _mm256_permutevar8x32_ps for 32bit. But I need a more generic solution to shift by x bytes. Has anybody already a solution for this problem?

Community
  • 1
  • 1
martin s
  • 1,121
  • 1
  • 12
  • 29
  • 3
    If you find yourself needing to do this a lot, you might want to think of an alternate approach. AVX and beyond breaks up the vectors into "lanes" of 128-bit. Cross-lane operations are very expensive. Looking at Agner Fog's docs, it looks like cross-lane operations are more expensive than misaligned memory access. – Mysticial Dec 25 '13 at 19:09
  • thanks a lot for the answer. I will checkout his docs. But I don't have to use the command extensive. But it would be good if I could use SIMD commands. – martin s Dec 25 '13 at 19:14
  • Is the shift amount a compile-time constant? – Iwillnotexist Idonotexist Dec 25 '13 at 19:42
  • yes it is compile time – martin s Dec 25 '13 at 19:58
  • @Mysticial: It's a latency penalty, not throughput. `VPERMD y,y,y`, `VPERMQ y,y,i`, and `VPERM2I128 y,y,y,i` are all 1uop, lat=3c, throughput=1/cycle. (And all run on port5 only in Haswell.) I agree, if you can structure things to work without crossing lanes all the time, that's best. But if your algo inherently benefits, and the extra latency isn't killer, then it could be a win. – Peter Cordes Jun 09 '15 at 01:38

1 Answers1

11

okay I implemented a function that can shift left up to 16 byte.

template  <unsigned int N> __m256i _mm256_shift_left(__m256i a)
{
  __m256i mask =  _mm256_srli_si256(
          _mm256_permute2x128_si256(a, a, _MM_SHUFFLE(0,0,3,0))
          , 16-N);
  return _mm256_or_si256(_mm256_slli_si256(a,N),mask);
}

Example:

int main(int argc, char* argv[]) {
   __m256i reg =  _mm256_set_epi8(32,31,30,29,28,27,26,25,24,23,22,21,20,19,18,17,16,15,
                                  14,13,12,11,10,9,8,7,6,5,4,3,2,1);

   __m256i result = _mm256_shift_left<1>(reg);
   for(int i = 0; i < 32; i++)
     printf("%2d ",((unsigned char *)&result)[i]);
   printf("\n");
}

The output is
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Edit: New version with new alignr instruction. Thanks for the hint @Evgney Kluev

template  <unsigned int N> __m256i _mm256_shift_left(__m256i a)
{
  __m256i mask = _mm256_permute2x128_si256(a, a, _MM_SHUFFLE(0,0,3,0) );
  return _mm256_alignr_epi8(a,mask,16-N);
}
martin s
  • 1,121
  • 1
  • 12
  • 29
  • 4
    You could optimize this by using `_mm256_alignr_epi8` instead of both shifts and "or". – Evgeny Kluev Dec 30 '13 at 12:25
  • @EvgenyKluev thanks thats really a nice instruction. I could reduce it now to two instructions. – martin s Dec 30 '13 at 16:21
  • 1
    Does anyone know why VPALIGNRB (_mm256_alignr_epi8) is not in Agner Fog's instruction tables? I want to know the latency and throughput. – Z boson Jan 03 '14 at 12:04
  • 3
    @Zboson: I don't know why Agner Fog skipped it. But [this resource](http://users.atw.hu/instlatx64/GenuineIntel00306C3_Haswell_InstLatX64.txt) reports both latency and throughput to be exactly one clock. – Evgeny Kluev Jan 03 '14 at 12:41
  • 1
    Old comment, so maybe it was missing 1.5 years ago, but `PALIGNR v,v,i / v,v,v,i` is listed for Haswell in Agner Fog's insn tables. He only lists insns with the V prefix if there is no non-AVX version. Otherwise the non-V mnemonic is there, and you have to look at the args to see if there's a different entry if there's a difference between using it on `xmm` and `ymm` args. – Peter Cordes Jun 09 '15 at 01:34
  • 1
    @BeeOnRope: heh, yup. I neglected to include the latency and throughput though. Oh well, pretty much all in-lane shuffles have the same latency and throughput on Haswell. – Peter Cordes Dec 27 '16 at 07:20