hard register reload patch

[Bernd Schmidt]

>   > That is a different issue.  The combiner problem I had caused an explicit
>   > hard register reference to %ecx to be substituted into a shift insn with
>   > variable count (and variations on that theme), causing a spill failure
>   > later.
> Hmm, I might be confusing the combiner problem with a sched1 problem on the
> x86 that is related to S_R_C targets.  My apologies.

Here's an example program that exposes the problem:

  int foo (int, int) __attribute__ ((regparm (3)));

  int foo (int x, int y)
  {
    asm volatile("" : : "d" (x), "r" (y));
  }

Here's the relevant portion of the .combine dump:

(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.

[I assume this is OK for gcc.dg?]

Bernd