Re: [MIPS] Test case dspr2-MULT is failed

[Chung-Lin Tang <cltang at codesourcery dot com>]

On 2010/12/31 09:38 PM, Richard Sandiford wrote:
> Mingjie Xing <mingjie.xing@gmail.com> writes:
>> There are two test cases failed when run 'make check-gcc
>> RUNTESTFLAGS="mips.exp"'.  The log is,
>>
>> Executing on host: /home/xmj/tools/build-test-trunk-mips/gcc/xgcc
>> -B/home/xmj/tools/build-test-trunk-mips/gcc/
>> /home/xmj/tools/test-trunk/gcc/testsuite/gcc.target/mips/dspr2-MULT.c
>>  -DNOMIPS16=__attribute__((nomips16)) -mabi=32 -mips32r2 -mgp32 -O2
>> -mdspr2 -mtune=74kc -ffixed-hi -ffixed-lo -S  -o dspr2-MULT.s
>> (timeout = 300)
>> PASS: gcc.target/mips/dspr2-MULT.c (test for excess errors)
>> PASS: gcc.target/mips/dspr2-MULT.c scan-assembler \tmult\t
>> PASS: gcc.target/mips/dspr2-MULT.c scan-assembler ac1
>> FAIL: gcc.target/mips/dspr2-MULT.c scan-assembler ac2
>> Executing on host: /home/xmj/tools/build-test-trunk-mips/gcc/xgcc
>> -B/home/xmj/tools/build-test-trunk-mips/gcc/
>> /home/xmj/tools/test-trunk/gcc/testsuite/gcc.target/mips/dspr2-MULTU.c
>>   -DNOMIPS16=__attribute__((nomips16)) -mabi=32 -mips32r2 -mgp32 -O2
>> -mdspr2 -mtune=74kc -ffixed-hi -ffixed-lo -S  -o dspr2-MULTU.s
>> (timeout = 300)
>> PASS: gcc.target/mips/dspr2-MULTU.c (test for excess errors)
>> PASS: gcc.target/mips/dspr2-MULTU.c scan-assembler \tmultu\t
>> PASS: gcc.target/mips/dspr2-MULTU.c scan-assembler ac1
>> FAIL: gcc.target/mips/dspr2-MULTU.c scan-assembler ac2
>>
>> Is it a bug?
> 
> It's a register-allocation optimisation regression that's been around
> for quite a long time now (probably over a year).  We're not making as
> much use of the 4 accumulator registers as we should.
> 
> In truth, I don't think we ever really made good use of them anyway.
> ISTR that trivial modifications of the testcase failed even before
> the regression.

I analyzed this testcase regression a while earlier; the direct cause of
this is due to mips_order_regs_for_local_alloc(), which now serves as
MIPS' ADJUST_REG_ALLOC_ORDER macro.

The mips_order_regs_for_local_alloc() function seems to be written for
the old local-alloc.c, still left as the deprecated
ORDER_REGS_FOR_LOCAL_ALLOC macro after the transition to IRA (actually
not called at all during then), and relatively recently 'revived' after
a patch by Bernd that created the ADJUST_REG_ALLOC_ORDER macro went in.

So you have a local-alloc.c heuristic working in IRA, which seemed to
cause these regressions.

Removing mips_order_regs_for_local_alloc() will let this testcase pass;
of course the real fix should be to review the MIPS reg-ordering logic,
left for you MIPS people...

Chung-Lin