On 2010/12/31 09:38 PM, Richard Sandiford wrote: > Mingjie Xing <mingjie.x...@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
