> 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
