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

[Jeff Law]

On 10/27/14 13:33, Georg-Johann Lay wrote:
> Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek:
>> On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
>>> 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.
>>
>> It can happen, but if it happens, that would mean user code bug, like
>> using
>> register asm with an register that is unsuitable for use as global or
>> local
>> register var on the target, or it could be backend bug (expansion of some
>> pattern clobbering register that has other fixed uses).
>> You shouldn't ICE on it, but what happens is undefined.
>
> Now I have a test case where exact that happens:
>
> - An expander needs to clobber a hard register.
> - That hard reg is live at that time and *not* used as operand to the
> expander
> - That hard reg is neither fixed nor a global register.
> - That hard reg is neither used for argument passing nor for frame pointer
>    or stack pointer and not for any exotic use like static chain etc.
So can you give more details about the live hard reg?  How did a value 
get into that hard reg, how did it get used later? That's where I'd 
focus my efforts since that probably shouldn't be happening except in 
very special circumstances.



jeff

>