Re: PR37363: PR36090 and PR36182 all over again

[Paolo Bonzini <bonzini at gnu dot org>]

> As H-P says, the predicates on move expanders are generally ignored.
> emit_move_insn & subroutines deliberately don't check them.

It's even worse; force_reg is effectively hardcoding movXX's operand 1
to be a general_operand.  (But my point was that force_reg does use
LEGITIMATE_CONSTANT_P through general_operand).

>> Not necessarily; anything that's found in a non-legitimate constant must
>> be handled by force_reg, and force_reg also tries using force_operand if
>> what it gets is not a general_operand.  But maybe it's necessary to add a
>>
>>   if (GET_CODE (value) == CONST)
>>     value = XEXP (value, 0);
>>
>> in force_operand.
> 
> As you say, force_operand currently does nothing with constants.
> My understanding is that that really is by design (in the loosest
> possible sense of the word).  As H-P says, it's then the move expander's
> responsibility to handle the thing.

force_reg is weird:

1) it tries the move expander if operand 1 is a general_operand first;

2) it tries force_operand if it is not;

3) it tries the move expander if force_operand fails.

It would make sense to have something like: 1) check the move expander's
predicate; 2) try force_operand; 3) abort.  But I agree that it is not a
lightweight to change it, and I wouldn't propose it -- especially now.
OTOH every message in this thread is highlighting something fishy.

> would in some cases be accurate.)  I think using an unspec in rs6000
> would solve some of the port-specific issues.  In particular, I don't
> think 36090 would have happened with an unspec representation.

I agree.  So your plan would be to change rs6000 to an unspec, and drop
the problematic hunk in simplify-rtx.c?  That would be okay with me, but
it's not a small change for rs6000.

Paolo