http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762
--- Comment #24 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2011-11-11
13:04:02 UTC ---
(In reply to comment #22)
> Yeah, this is also what I thought at the first sight. But please don't forget
> that additional c-code test effectively creates
>
> (and (match_operand (...)
> (match_test (call to c-code)))
>
> and this construct will _always_ force generation of mode checks.
No, it actually does not; see e.g. in the x86-64 insn-preds.c we have
(define_predicate "long_memory_operand"
(and (match_operand 0 "memory_operand")
(match_test "memory_address_length (op)")))
implemented as:
int
long_memory_operand (rtx op, enum machine_mode mode ATTRIBUTE_UNUSED)
{
return (memory_operand (op, mode)) && (
#line 994 "../../gcc-head/gcc/config/i386/predicates.md"
(memory_address_length (op)));
}
This is because the genpred routines have code to follow boolean
operators and reason correctly that if match_operand performs the
mode test, and some other test is joined via "and", the test is
still not necessary.
In fact, except for the address_operand case, the mode checks seem
to be correct in their actual effect: we either call a standard operator
and omit the mode check, or else we have the genpred-generated mode check,
but in conjunction with some match_code test that excludes CONST_INT
and CONST_DOUBLE anyway.
