http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53074

             Bug #: 53074
           Summary: insn-recog.c:recog calls predicates known to be false
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P3
         Component: middle-end
        AssignedTo: unassig...@gcc.gnu.org
        ReportedBy: h...@gcc.gnu.org
            Target: cris-axis-elf


The following was observed for gcc-4_7-branch r185763 as well as for trunk
r186667.

The decision-tree in insn-recog.c, when generated from candidate patterns where
one candidate (the first in file) pattern has a bare (label_ref ...) (without
specified mode) and others (after the first in the file) has (match_operand:SI
"operand_known_to_not_match_label_ref" ...) where
operand_known_to_not_match_label_ref is for example, nonimmediate_operand or
register_operand, inspects the mode of the operand of the insn being matched
and calls the predicates despite it knowing they will fail.  After the calls,
it will correctly match the insn to the first pattern.  This will not happen if
the predicate is not known to fail or when no mode is specified for the second
pattern (then there's the expected test for LABEL_REF).  It should instead
always first check the operand to be LABEL_REF, matching the first pattern.

I'm labelling this as "missed optimization"; I can't make a strong case that
the predicate call should be considered wrong-code, though the argument would
be that it could assert, as there's no point calling it for a label_ref as the
first pattern will always match.

It could be that this is a special-case and that inspecting mode and calling
predicates is seen as cheaper than inspecting the actual operand code and
matching any mode, but at face value it doesn't make sense, in particular as
the rules are that the first pattern has to match.

See <http://gcc.gnu.org/ml/gcc/2012-04/msg00771.html> for actual generated code
and further discussion.

Reply via email to