User account creation filtered due to spam.

Bug 53074 - insn-recog.c:recog calls predicates known to be false before matching bare RTL code
Summary: insn-recog.c:recog calls predicates known to be false before matching bare RT...
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.8.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: missed-optimization
Depends on:
Reported: 2012-04-22 18:37 UTC by Hans-Peter Nilsson
Modified: 2012-04-22 18:40 UTC (History)
0 users

See Also:
Target: cris-axis-elf
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Hans-Peter Nilsson 2012-04-22 18:37:55 UTC
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 <> for actual generated code and further discussion.