Re: hard register reload patch

[Joern Rennecke <amylaar at cygnus dot co dot uk>]

> (insn 12 7 16 (parallel[ 
>             (asm_operands/v ("") ("") 0[ 
>                     (reg/v:SI 24)
>                     (reg:SI 1 edx)
>                 ] 
>                 [ 
>                     (asm_input:SI ("d"))
>                     (asm_input:SI ("r"))
>                 ]  ("/tmp/rp.c") 6)
>             (clobber (reg:QI 18 fpsr))
>             (clobber (reg:QI 17 flags))
>         ] ) -1 (insn_list 4 (nil))
>     (expr_list:REG_DEAD (reg:SI 1 edx)
>         (expr_list:REG_UNUSED (reg:QI 17 flags)
>             (expr_list:REG_UNUSED (reg:QI 18 fpsr)
>                 (expr_list:REG_DEAD (reg/v:SI 24)
>                     (nil))))))
> 
> Previously, the argument register %edx was copied to a pseudo, and that pseudo
> was used in the asm insn.  The combiner decided to eliminate the move and
> substitute the hard reg into the asm insn.  Unfortunately, there's another
> operand in this insn which requires the same reg.  This causes a spill
> failure later.  I'm not sure whether Joerns patch helps here; I need to try
> it I guess.  Still, I'm of the very strong opinion that we should never ever
> let the combiner do transformations like this.

No, my patch doesn't help in this case.  The two input operands conflict.

On the other hand, there are cases when such transformations are desired.
There are a number of ways how we could distinguish these cases:

- The hard register is in a single-register register class, and is a
  non-fixed register.
- We could have a target macro to say which register classes should be
  exempt from combining into instructions that have multiple inputs / outputs.
- We could check if there is an operand constraint that requires the particular
  hard register in question.