PR63633: May middle-end come up width hard regs for insn expanders?

[Jeff Law]

On 10/24/14 12:19, Georg-Johann Lay wrote:
>
> 1) May it happen that a value lives in a hard-reg across the expander?
> The expander has no means to detect that situation and interfere, e.g.
>
> hard-reg = source_value // middle-end
> expand-code             // back-end
> sink_value = hard-reg   // middle-end
>
> where "expand-code" is one defind_expand / define_insn that clobbers /
> changes (parts of) hard-reg but does *not* get hard-reg as operand. This
> is wrong code obviously.
This shouldn't be happening, the compiler certainly isn't going to set 
up something like this without the user doing something horribly wrong 
(see Jakub's reply).

There's no need for you to try and detect this.

>
>
> 2) May later, non-strict-rtl passes also come up with such situations,
> e.g. as they are using the same middle-end functions to emit their code?
>
> One example is expmed.c:expand_divmod() which is called from RTL loop
> optimizers (and stumbles upon PR59559 btw.)
>
> What if no new pseudos are available at that time?
You can create new pseudos pretty much up until register allocation begins.

So, assume you can create a pseudo unless can_create_pseudo() returns 
false.  If you have a case where an input is a hard reg and there's an 
overlapping clobber and !can_create_pseudo_p, then you could ICE or go 
to heroic measures to generate code (creating stack slots, shoving 
values into the stack slots, generate code, restore from stack slots, 
deallocate stack).  Choice really depends on the validity of the input 
code...

As Jakub states, except for parameter passing it's best to avoid 
explicitly mentioned hard registers until allocation.  I've never looked 
closely at your port, but you might even consider creating a register 
class for the set of registers you need to clobber, then clobber a 
pseudo of that class.  That can often help register allocation.

jeff