Eric Bron (eric.bron.delete@this.zvisuel.privatefortest.com) on January 8, 2014 12:15 pm wrote:
> > keyword does get ICC to introduce some interleaving.
>
> indeed, I can confirm this for AVX-512 :
>
> without __restrict :
>
>
> .B2.8:: ; Preds .B2.8 .B2.7
> vmovups zmm4, ZMMWORD PTR [r15+r10*8] ;104.13
> vfmadd213pd zmm4, zmm2, zmm3 ;105.19
> vfmadd132pd zmm4, zmm0, ZMMWORD PTR [r15+r10*8] ;105.29
> vfmadd231pd zmm4, zmm1, ZMMWORD PTR [r15+r10*8] ;105.32
> vmovups ZMMWORD PTR [r11+r10*8], zmm4 ;105.2
> vmovups zmm5, ZMMWORD PTR [64+r15+r10*8] ;104.13
> vfmadd213pd zmm5, zmm2, zmm3 ;105.19
> vfmadd132pd zmm5, zmm0, ZMMWORD PTR [64+r15+r10*8] ;105.29
> vfmadd231pd zmm5, zmm1, ZMMWORD PTR [64+r15+r10*8] ;105.32
> vmovups ZMMWORD PTR [64+r11+r10*8], zmm5 ;105.2
> vmovups zmm16, ZMMWORD PTR [128+r15+r10*8] ;104.13
> vfmadd213pd zmm16, zmm2, zmm3 ;105.19
> vfmadd132pd zmm16, zmm0, ZMMWORD PTR [128+r15+r10*8] ;105.29
> vfmadd231pd zmm16, zmm1, ZMMWORD PTR [128+r15+r10*8] ;105.32
> vmovups ZMMWORD PTR [128+r11+r10*8], zmm16 ;105.2
> vmovups zmm17, ZMMWORD PTR [192+r15+r10*8] ;104.13
> vfmadd213pd zmm17, zmm2, zmm3 ;105.19
> vfmadd132pd zmm17, zmm0, ZMMWORD PTR [192+r15+r10*8] ;105.29
> vfmadd231pd zmm17, zmm1, ZMMWORD PTR [192+r15+r10*8] ;105.32
> vmovups ZMMWORD PTR [192+r11+r10*8], zmm17 ;105.2
> add r10, 32 ;103.2
> cmp r10, rax ;103.2
> jb .B2.8 ; Prob 82% ;103.2
>
>
> with __restrict :
>
>
> .B2.4:: ; Preds .B2.4 .B2.3
> vmovups zmm4, ZMMWORD PTR [r11+r9*8] ;103.13
> vmovups zmm5, ZMMWORD PTR [64+r11+r9*8] ;103.13
> vmovups zmm16, ZMMWORD PTR [128+r11+r9*8] ;103.13
> vmovups zmm17, ZMMWORD PTR [192+r11+r9*8] ;103.13
> vfmadd213pd zmm4, zmm1, zmm2 ;104.19
> vfmadd213pd zmm5, zmm1, zmm2 ;104.19
> vfmadd213pd zmm16, zmm1, zmm2 ;104.19
> vfmadd213pd zmm17, zmm1, zmm2 ;104.19
> vfmadd132pd zmm4, zmm3, ZMMWORD PTR [r11+r9*8] ;104.29
> vfmadd132pd zmm5, zmm3, ZMMWORD PTR [64+r11+r9*8] ;104.29
> vfmadd132pd zmm16, zmm3, ZMMWORD PTR [128+r11+r9*8] ;104.29
> vfmadd132pd zmm17, zmm3, ZMMWORD PTR [192+r11+r9*8] ;104.29
> vfmadd231pd zmm4, zmm0, ZMMWORD PTR [r11+r9*8] ;104.32
> vmovups ZMMWORD PTR [r10+r9*8], zmm4 ;104.2
> vfmadd231pd zmm5, zmm0, ZMMWORD PTR [64+r11+r9*8] ;104.32
> vmovups ZMMWORD PTR [64+r10+r9*8], zmm5 ;104.2
> vfmadd231pd zmm16, zmm0, ZMMWORD PTR [128+r11+r9*8] ;104.32
> vmovups ZMMWORD PTR [128+r10+r9*8], zmm16 ;104.2
> vfmadd231pd zmm17, zmm0, ZMMWORD PTR [192+r11+r9*8] ;104.32
> vmovups ZMMWORD PTR [192+r10+r9*8], zmm17 ;104.2
> add r9, 32 ;102.2
> cmp r9, rdx ;102.2
> jb .B2.4 ; Prob 82% ;102.2
>

That code is much more reasonable.
Here compiler's insistence on using the same memory operand over and over has much simpler explanation than mythical ultra-efficient L0 cache. That's optimization for a front end that can decode, say 2-eps1 load+op instructions vs 2-eps2 RISC-like instruction where the difference between eps1 and eps2 is too small to justify the cost of reuse. And the cost of reuse in this case is not small - 1 register move per two avoided load+op instructions, i.e. 27 instructions per iteration instead of 23. In this case the loop is small enough to fit in LSD, so I fully believe that 15 simple + 8 complex instructions are executed faster than 27 simple instructions. And the number of loads per instruction is only very slightly higher than 0.5 so we can make no conclusions about availability of the second load port.

The root cause for code generation like that is an absence of non-destructive FMA in AVX512F ISA. With FMA4 the problem that compiler solved by load+op simply wouldn't exist.

BTW, I would like to see the code generated for KNC when all the rest is exactly as above.