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