Other target-patches exposed this for me.
I have on the 4.7-branch an insn:
(jump_insn 245 277 246 (set (pc)
(label_ref:SI 312)) whatever.c:511 -1
(nil)
-> 187)
and two (or more) pattern candidates in the following .md file
order:
(define_insn "jump"
[(set (pc)
(label_ref (match_operand 0 "" "")))]
""
"ba %l0%#"
[(set_attr "slottable" "has_slot")])
(define_insn "*indirect_jump_non_v32"
[(set (pc) (match_operand:SI 0 "nonimmediate_operand" "rm"))]
"!TARGET_V32"
"jump %0")
As you know (or may want to dispute for some reason, so let's
settle that first), operands without specified modes on matching
patterns are wild-card matches; not VOIDmode matches or a kind
of lesser-order matches.
(ISTR some change, at least some discussion, that label_refs now
should have modes, but if the change happened, the documentation
wasn't sufficiently updated. If so, the mode on the
"jump"-pattern above should be :SI, but when it's not specified,
it's a wild-card, so should still *match*. It could also be
that the :SI is put there in error, but still the pattern
recognition order observation is valid.)
It seems that since 4.3, some change now causes the generated
pattern-matching tree in insn-recog.c:recog to try the pattern
*with the specified mode* before (eventually, seemingly last)
the one with the unspecified-mode label_ref.
What I'll do next depends. Is there a reason to keep that
change (and document it) or should the bug just be fixed?
brgds, H-P
