Re: hard register reload patch

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

> This is the simple case, where there's only one such insn.  Now consider the
> case where we have more than one such insn.  Say the pseudos involved are X
> and Y.  Your concern seems to be: what happens if an optimizer makes X and Y
> live at the same time?  I believe we get the same end result again.  What

That's not the whole story.  The optimizers can also move the insn that
uses X and Y.

consider this snippet of code:

f (int x, int y)
{
  switch (i)
    {
    case 0:
      foo ((float) x);
      break;
    case 1:
      bar ((float) x);
      break;
    case 2:
      foo ((float) y);
      break;
    case 3:
      bar ((float) y);
      break;
    }
}

When you compile this with -Os, and your pseudo using pattern is in place,
you can expect code hoisting to hoist out the conversions of x and y.
So hey cannot any longer use the function argument registers as outputs,
but must use some other floating point register, which then need copied to
the actual argument registers.  No space saved, but some time wasted.

> Yup, it probably would fix these two cases.  I'm not convinced, however, that
> the combiner won't ever extend hard reg lifetimes across an insn that
> requires a reload in a single-register class.  If it does, we'll lose
> (eventually).

No, on SMALL_REGISTER_CLASSES machines, the combiner only puts hard regs
into insns if their lifetime already reach just before or after that insn.