With some trepidation, because I suspect I'm missing the point :-)
Hans-Peter Nilsson <
hans-peter.nilsson@...> 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
