[IRA] Handle fully-tied destinations in a similar way to earlyclobbers
authorRichard Sandiford <richard.sandiford@arm.com>
Mon, 7 Oct 2019 08:39:12 +0000 (08:39 +0000)
committerRichard Sandiford <rsandifo@gcc.gnu.org>
Mon, 7 Oct 2019 08:39:12 +0000 (08:39 +0000)
commit9b0365879b3c4917f5a2485a1fca8bb678484bfe
treee195e5f08879e121f8ccf818cb2dfe2e11a2ad3e
parentad00d6c1746fdcbfd86b2d50f2500d7ccb0d1691
[IRA] Handle fully-tied destinations in a similar way to earlyclobbers

IRA's make_early_clobber_and_input_conflicts checks for cases in
which an output operand is likely to be an earlyclobber and an input
operand is unlikely to be tieable with it.  If so, the allocno for
the output conflicts with the allocno for the input.  This seems
to work well.

However, a similar situation arises if an output operand is likely
to be tied to one of a set of input operands X and if another input
operand has a different value from all of the operands in X.
E.g. if we have:

  0: "=r, r"
  1: "0, r"
  2: "r, 0"
  3: "r, r"

operand 0 will always be tied to operand 1 or operand 2, so if operand 3
is different from them both, operand 0 acts like an earlyclobber as far
as operand 3 (only) is concerned.  The same is true for operand 2 in:

  0: "=r"
  1: "0"
  2: "r"

In the second example, we'd normally have a copy between operand 1 and
operand 0 if operand 1 dies in the instruction, and so there's rarely
a problem.  But if operand 1 doesn't die in the instruction, operand 0
still acts as an earlyclobber for operand 2 (if different from operand 1),
since in that case LRA must copy operand 1 to operand 0 before the
instruction.

As the existing comment says:

    Avoid introducing unnecessary conflicts by checking classes of the
    constraints and pseudos because otherwise significant code
    degradation is possible for some targets.

I think that's doubly true here.  E.g. it's perfectly reasonable to have
constraints like:

  0: "=r, r"
  1: "0, r"
  2: "r, r"

on targets like s390 that have shorter instructions for tied operands,
but that don't want the size difference to influence RA too much.
We shouldn't treat operand 0 as earlyclobber wrt operand 2 in that case.

This patch therefore treats a normal tied non-earlyclobber output as
being effectively earlyclobber wrt to an input if it is so for *all*
preferred alternatives.

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

gcc/
* ira-lives.c (check_and_make_def_conflict): Handle cases in which
DEF is not a true earlyclobber but is tied to a specific input
operand, and so is effectively earlyclobber wrt inputs that have
different values.
(make_early_clobber_and_input_conflicts): Pass this case to the above.

From-SVN: r276650
gcc/ChangeLog
gcc/ira-lives.c