On 7/5/19 2:51 AM, Richard Sandiford wrote: > 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. > > Tested on mipsisa64-elf. OK to install? > > Richard > > > 2019-07-05 Richard Sandiford <richard.sandif...@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. Dredging up memories of past work? :) I certainly wonder how much crud we have in the target files that's just not desirable anymore given how far things have moved. But I'm also not terribly inclined to spend the time to figure that out for the embedded targets ;-)
OK. Jeff
