[Bug middle-end/53074] insn-recog.c:recog calls predicates known to be false before matching bare RTL code

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #1 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Hans-Peter Nilsson from comment #0)
> 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.

cc-ing Richard from that thread