Re: What to do about pattern recognition not in .md order when the mode of a pattern operand is unspecified

[Richard Sandiford <rdsandiford at googlemail dot com>]

With some trepidation, because I suspect I'm missing the point :-)

Hans-Peter Nilsson <hans-peter.nilsson@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