[Bug target/51729] New: dspr2-MULT.c and dspr2-MULTU.c fail for MIPS

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51729

             Bug #: 51729
           Summary: dspr2-MULT.c and dspr2-MULTU.c fail for MIPS
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rsandifo@gcc.gnu.org


dspr2-MULT.c and dspr2-MULTU.c are supposed to test that we use the
DSP accumulator registers to parallelise multiplications.  They don't
work in 4.7, and I'm about to XFAIL them.  There seem to be two main
problems:

* The cost of moving between DSP accumulators is greater than the cost
  of moving a DSP register to or from memory.  When I last looked,
  this was enough to make the register allocator consider memory to
  be cheaper.

  This isn't a problem without -mdsp because there is then only one
  accumulator register, LO+HI.  (Note that we no longer allow HI and
  LO to store independent values.)  The cost of moving between accumulators
  is therefore ignored.

  On some (many?) targets, moving something out of an accumulator
  and back again _is_ more expensive than storing an accumulator
  to memory, so this isn't necessarily a bug in the backend.

* Even if we massage the costs to avoid that problem, each of the pseudos
  that we'd like to use accumulators has one "=ka" constraint and one
  "d" constraint.  At one point this meant that DSP_REGS and GENERAL_REGS
  had the same cost, and reg_alloc_order could be used to prefer accumulators:

    http://gcc.gnu.org/ml/gcc/2010-12/msg00471.html
    http://gcc.gnu.org/ml/gcc/2011-01/msg00093.html

  But GENERAL_REGS now seems to have a lower cost, and since GENERAL_REGS
  are much easier to spill than DSP_REGS, it's hard to argue with that.