PR91068: Fix MIPS fallout from IRA matched operand changes

PR91068: Fix MIPS fallout from IRA matched operand changes

PR91068 is a case in which we have (ignoring non-LRA alternatives):

  [(set (match_operand:SI 0 "register_operand" "=l,d?")
	(plus:SI (mult:SI (match_operand:SI 1 "register_operand" "d,d")
			  (match_operand:SI 2 "register_operand" "d,d"))
		 (match_operand:SI 3 "register_operand" "0,d")))
   (clobber (match_scratch:SI 4 "=X,l"))
   (clobber (match_scratch:SI 5 "=X,&d"))]

where the first alternative is one instruction but the second is two.
This is very similar to the case that my recent IRA patches were
supposed to help.  The crucial difference is that the cheap
alternative requires a single-register class while the expensive
alternative uses general registers.

This makes a difference when one of operand 0 or 3 can naturally be
allocated to LO but the other can't.  If IRA makes that allocation,
both alternatives require one reload of equal cost and so the first
alternative clearly wins.

However, if we say that tying operands 0 and 3 saves the cost of a full
move, then all other things being equal, IRA will prefer to allocate
both registers to the same GPR.  The registers will then naturally
fit the second alternative.

This has a more drastic effect in the MIPS case than it should because
using the GPR alternative is much more expensive there than it appears
to the RA.  But that's really a separate problem and something we were
able to live with before my IRA patch.

What makes tying less useful here is the fact that the tied register is
a single-register class.  I think in those circumstances it's better not
to use tied operands at all and instead use "l" for the inputs.
Allocating the input to LO, and allocating the output to LO, then depend
naturally on class costs.  If we decide to allocate at least one of them
to LO, we'll use the cheap alternative, otherwise we'll (correctly) use
the expensive alternative.  This effectively restores the situation
before my IRA patch, but this time making the preference on the input
register more explicit.

I originally wrote the patterns in the early days of IRA, and certainly
well before LRA.  I think they were largely influened by reload rather
than RA proper (see the comment above *mul_acc_si, which is all about
the reload behaviour).  LRA copes with the two-"l" case just fine.

The patch may well cause problems for -mno-lra, but I think we should
cull that option anyway.

2019-07-07  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
	PR target/91068
	* config/mips/mips.md (*mul_acc_si, *mul_acc_si_r3900, *macc)
	(*msac, *msac_using_macc, *mul_sub_si): Use "l" for input operands
	instead of matching them to "l" output operands.

From-SVN: r273175