[Bug middle-end/95899] -funroll-loops does not duplicate accumulators when calculating reductions, failing to break up dependency chains

["elrodc at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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.