-
- Downloads
recog/reload: Remove old UNARY_P operand support
reload and constrain_operands had some old code to look through unary operators. E.g. an operand could be (sign_extend (reg X)), and the constraints would match the reg rather than the sign_extend. This was previously used by the MIPS port. But relying on it was a recurring source of problems, so Eric and I removed it in the MIPS rewrite from ~20 years back. I don't know of any other port that used it. Also, the constraints processing in LRA and IRA do not have direct support for these embedded operators, so I think it was only ever a reload-specific feature (and probably only a global/local+reload-specific feature, rather than IRA+reload). Keeping the checks caused problems for special memory constraints, leading to: /* A unary operator may be accepted by the predicate, but it is irrelevant for matching constraints. */ /* For special_memory_operand, there could be a memory operand inside, and it would cause a mismatch for constraint_satisfied_p. */ if (UNARY_P (op) && op == extract_mem_from_operand (op)) op = XEXP (op, 0); But inline asms are another source of problems. Asms don't have predicates, and so we can't use recog to decide whether a given change to an asm gives a valid match. We instead rely on constrain_operands as something of a recog stand-in. For an example like: void foo (int *ptr) { asm volatile ("%0" :: "r" (-*ptr)); } any attempt to propagate the negation into the asm would be allowed, because it's the negated register that would be checked against the "r" constraint. This would later lead to: error: invalid 'asm': invalid operand The same thing happened in gcc.target/aarch64/vneg_s.c with the upcoming late-combine pass. Rather than add more workarounds, it seemed better just to delete this code. gcc/ * recog.cc (constrain_operands): Remove UNARY_P handling. * reload.cc (find_reloads): Likewise.
Loading
Please register or sign in to comment