title: Wrong gcc generated assembly ordering, results in performance hit
body: <p>I have got the following code, which copies data from memory to DMA buffer:</p>
  
  <pre><code>for (; likely(l &gt; 0); l-=128)
  {
      __m256i m0 = _mm256_load_si256( (__m256i*) (src) );
      __m256i m1 = _mm256_load_si256( (__m256i*) (src+32) );
      __m256i m2 = _mm256_load_si256( (__m256i*) (src+64) );
      __m256i m3 = _mm256_load_si256( (__m256i*) (src+96) );
  
      _mm256_stream_si256( (__m256i *) (dst), m0 );
      _mm256_stream_si256( (__m256i *) (dst+32), m1 );
      _mm256_stream_si256( (__m256i *) (dst+64), m2 );
      _mm256_stream_si256( (__m256i *) (dst+96), m3 );
  
      src += 128;
      dst += 128;
  }
  </code></pre>
  
  <p>That is how <code>gcc</code> assembly output looks like:</p>
  
  <pre><code>405280:       c5 fd 6f 50 20          vmovdqa 0x20(%rax),%ymm2
  405285:       c5 fd 6f 48 40          vmovdqa 0x40(%rax),%ymm1
  40528a:       c5 fd 6f 40 60          vmovdqa 0x60(%rax),%ymm0
  40528f:       c5 fd 6f 18             vmovdqa (%rax),%ymm3
  405293:       48 83 e8 80             sub    $0xffffffffffffff80,%rax
  405297:       c5 fd e7 52 20          vmovntdq %ymm2,0x20(%rdx)
  40529c:       c5 fd e7 4a 40          vmovntdq %ymm1,0x40(%rdx)
  4052a1:       c5 fd e7 42 60          vmovntdq %ymm0,0x60(%rdx)
  4052a6:       c5 fd e7 1a             vmovntdq %ymm3,(%rdx)
  4052aa:       48 83 ea 80             sub    $0xffffffffffffff80,%rdx
  4052ae:       48 39 c8                cmp    %rcx,%rax
  4052b1:       75 cd                   jne    405280 &lt;sender_body+0x6e0&gt;
  </code></pre>
  
  <p>Note the reordering of last <code>vmovdqa</code> and <code>vmovntdq</code> instructions. With the <code>gcc</code> generated code above I am able to reach throughput of ~10 227 571 packets per second in my application.</p>
  
  <p>Next, I reorder that instructions manually in hexeditor. That means now the loop looks the following way:</p>
  
  <pre><code>405280:       c5 fd 6f 18             vmovdqa (%rax),%ymm3
  405284:       c5 fd 6f 50 20          vmovdqa 0x20(%rax),%ymm2
  405289:       c5 fd 6f 48 40          vmovdqa 0x40(%rax),%ymm1
  40528e:       c5 fd 6f 40 60          vmovdqa 0x60(%rax),%ymm0
  405293:       48 83 e8 80             sub    $0xffffffffffffff80,%rax
  405297:       c5 fd e7 1a             vmovntdq %ymm3,(%rdx)
  40529b:       c5 fd e7 52 20          vmovntdq %ymm2,0x20(%rdx)
  4052a0:       c5 fd e7 4a 40          vmovntdq %ymm1,0x40(%rdx)
  4052a5:       c5 fd e7 42 60          vmovntdq %ymm0,0x60(%rdx)
  4052aa:       48 83 ea 80             sub    $0xffffffffffffff80,%rdx
  4052ae:       48 39 c8                cmp    %rcx,%rax
  4052b1:       75 cd                   jne    405280 &lt;sender_body+0x6e0&gt;
  </code></pre>
  
  <p>With the properly ordered instructions I get ~13 668 313 packets per second. So it is obvious that reordering introduced by <code>gcc</code> reduces performance.</p>
  
  <p>Have you come across that? Is this a known bug or should I fill a bug report?</p>
  
  <p>Compilation flags:</p>
  
  <pre><code>-O3 -pipe -g -msse4.1 -mavx
  </code></pre>
  
  <p>My gcc version:</p>
  
  <pre><code>gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
  </code></pre>