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

[Georg-Johann Lay]

Jeff Law schrieb:
> On 10/24/14 10:29, Jakub Jelinek wrote:
>>
>> But I'd say, if you can't handle hard regs in the operands (either 
>> general,
>> or some specific ones), you should
>> force the hard regs into pseudos (all hard regs, or just the problematic
>> ones) in the expander.
>> So in this case, check if they overlap with those 2 regs, and force the
>> input operands into pseudos if they do; the output will be harder, guess
>> you'd need to emit the pattern into a pseudo and emit_move_insn it
>> afterwards to the hard reg.
> I'm pretty sure that's what Georg is going to do, my comment was that 
> the existence of the hard register operand _may_ point to something else 
> that we would want to fix.
> 
> jeff

Yes, that's the straight forward approach which works so far.  Bit 
tedious, but well...

In one case expmed generated different code, though: divmodhi instead of 
mulhi_highpart for HI division by const_int.  Cheating with costs did 
not help.  However for now I am mostly after correct, ICE-less code.

What I am concerned about is:

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.


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?


The point is that the middle-end could know that it is generating bad 
code...


Johann