https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95899
--- Comment #2 from Chris Elrod <elrodc at gmail dot com> ---
Interesting. Compiling with:
gcc -march=native -fvariable-expansion-in-unroller -Ofast -funroll-loops -S
dot.c -o dot.s
Yields:
```
.L4:
vmovupd (%rdi,%r11), %zmm9
vmovupd 64(%rdi,%r11), %zmm10
vfmadd231pd (%rsi,%r11), %zmm9, %zmm0
vfmadd231pd 64(%rsi,%r11), %zmm10, %zmm1
vmovupd 128(%rdi,%r11), %zmm11
vmovupd 192(%rdi,%r11), %zmm12
vmovupd 256(%rdi,%r11), %zmm13
vfmadd231pd 128(%rsi,%r11), %zmm11, %zmm0
vfmadd231pd 192(%rsi,%r11), %zmm12, %zmm1
vmovupd 320(%rdi,%r11), %zmm14
vmovupd 384(%rdi,%r11), %zmm15
vmovupd 448(%rdi,%r11), %zmm4
vfmadd231pd 256(%rsi,%r11), %zmm13, %zmm0
vfmadd231pd 320(%rsi,%r11), %zmm14, %zmm1
vfmadd231pd 384(%rsi,%r11), %zmm15, %zmm0
vfmadd231pd 448(%rsi,%r11), %zmm4, %zmm1
addq $512, %r11
cmpq %r8, %r11
jne .L4
```
So the dependency chain has now been split in 2.
4 would be ideal. I'll try running benchmarks later to see how it does.
FWIW, the original ran at between 20 and 25 GFLOPS from roughly N = 80 through
N = 1024.
The fastest versions I benchmarked climbed from around 20 to 50 GFLOPS over
this range. So perhaps just splitting the dependency once can get it much of
the way there.
Out of curiosity, what's the reason for this being off by default for
everything but ppc?
Seems like it should turned on with `-funroll-loops`, given that breaking
dependency chains are one of the primary ways unrolling can actually help
performance.
