With some trepidation, because I suspect I'm missing the point :-) Hans-Peter Nilsson <hans-peter.nils...@axis.com> writes: > 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") [...] > 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.
This second one shouldn't match label_ref though, should it? label_ref is an immediate_operand. Was just wondering whether 4.3 was when the predicate codes thing was added, so that genrecog knew that nonimmediate_operand couldn't match. Richard
