Re: IRA vs CANNOT_CHANGE_MODE_CLASS, + 4.7 IRA regressions?

[Richard Guenther <richard dot guenther at gmail dot com>]

On Wed, Jul 27, 2011 at 11:59 PM, Sandra Loosemore
<sandra@codesourcery.com> wrote:
> Consider this bit of code:
>
> extern double a[20];
>
> double test1 (int n)
> {
> ?double accum = 0.0;
> ?int i;
>
> ?for (i=0; i<n; i++) { accum -= a[i]; }
> ?accum = fabs (accum);
> ?return accum;
> }
>
> which is compiled for MIPS using
>
> mipsisa32r2-sde-elf-gcc -O3 -fno-inline -fno-unroll-loops -march=74kf1_1 -S
> abstest.c
>
> With a GCC 4.6 compiler, this produces:
> ...
> .L3:
> ? ? ? ?mtc1 ? ?$3,$f2
> ? ? ? ?ldc1 ? ?$f0,0($5)
> ? ? ? ?addiu ? $5,$5,8
> ? ? ? ?mtc1 ? ?$2,$f3
> ? ? ? ?sub.d ? $f2,$f2,$f0
> ? ? ? ?mfc1 ? ?$3,$f2
> ? ? ? ?bne ? ? $5,$4,.L3
> ? ? ? ?mfc1 ? ?$2,$f3
>
> ? ? ? ?ext ? ? $5,$2,0,31
> ? ? ? ?move ? ?$4,$3
> .L2:
> ? ? ? ?mtc1 ? ?$4,$f0
> ? ? ? ?j ? ? ? $31
> ? ? ? ?mtc1 ? ?$5,$f1
> ...
>
> This is terrible code, with all that pointless register-shuffling inside the
> loop -- what's gone wrong? ?Well, the bit-twiddling expansion of "fabs"
> produced by optabs.c uses subreg expressions, and on MIPS
> CANNOT_CHANGE_MODE_CLASS disallows use of FP registers for integer
> operations. ?And, when IRA sees that, it decides it cannot alloc "accum" to
> a FP reg at all, even if it obviously makes sense to put it there for the
> rest of its lifetime.
>
> On mainline trunk, things are even worse as it's spilling to memory, not
> just shuffling between registers:
>
> .L3:
> ? ? ? ?ldc1 ? ?$f0,0($2)
> ? ? ? ?addiu ? $2,$2,8
> ? ? ? ?sub.d ? $f2,$f2,$f0
> ? ? ? ?bne ? ? $2,$3,.L3
> ? ? ? ?sdc1 ? ?$f2,0($sp)
>
> ? ? ? ?lw ? ? ?$2,0($sp)
> ? ? ? ?ext ? ? $3,$2,0,31
> ? ? ? ?lw ? ? ?$2,4($sp)
> .L2:
> ? ? ? ?sw ? ? ?$2,4($sp)
> ? ? ? ?sw ? ? ?$3,0($sp)
> ? ? ? ?lw ? ? ?$3,4($sp)
> ? ? ? ?lw ? ? ?$2,0($sp)
> ? ? ? ?addiu ? $sp,$sp,8
> ? ? ? ?mtc1 ? ?$3,$f0
> ? ? ? ?j ? ? ? $31
> ? ? ? ?mtc1 ? ?$2,$f1
>
> I've been experimenting with a patch to the MIPS backend to add
> define_insn_and_split patterns for floating-point abs -- the idea is to
> attach some constraints to the insns to tell IRA it needs a GP reg for these
> operations, so it can apply its usual cost analysis and reload logic instead
> of giving up. ?Then the split to introduce the subreg expansion happens
> after reload when we already have the right register class. ?This seems to
> work well enough on 4.6; for this particular example, I'm getting:
>
> .L3:
> ? ? ? ?ldc1 ? ?$f2,0($2)
> ? ? ? ?addiu ? $2,$2,8
> ? ? ? ?bne ? ? $2,$4,.L3
> ? ? ? ?sub.d ? $f0,$f0,$f2
>
> ? ? ? ?mfc1 ? ?$2,$f1
> ? ? ? ?ext ? ? $2,$2,0,31
> ? ? ? ?j ? ? ? $31
> ? ? ? ?mtc1 ? ?$2,$f1
>
> However, same patch on mainline is still giving spills to memory. ?:-(
>
> So, here's my question. ?Is it worthwhile for me to continue this approach
> of trying to make the MIPS backend smarter? ?Or is the way IRA deals with
> CANNOT_CHANGE_MODE_CLASS fundamentally broken and in need of fixing in a
> target-inspecific way? ?And/or is there some other regression in IRA on
> mainline that's causing it to spill to memory when it didn't used to in 4.6?
>
> BTW, the unary "neg" operator has the same problem as "abs" on MIPS; can't
> use the hardware instruction because it does the wrong thing with NaNs, and
> can't twiddle the sign bit directly in a FP register. ?With both abs/neg now
> generating unnecessary memory spills, this seems like a fairly important
> performance regression....

It sounds like IRA would benefit from properly split live-ranges here.
 You could try
to make the fabs optabs magic make sure to use a new pseudo (well, and hope
that survives ...)

Richard.

> -Sandra
>
>