pa indirect_jump instruction

[John David Anglin]

I would think pmode_register_operand is correct.  Then, condition can be 
removed.

Dave

On 2015-06-30 4:53 PM, Richard Sandiford wrote:
> I have a series of patches to convert all non-optab instructions to
> the target-insns.def interface.  config-list.mk showed up one problem
> though.  The pa indirect_jump pattern is:
>
> ;;; Hope this is only within a function...
> (define_insn "indirect_jump"
>    [(set (pc) (match_operand 0 "register_operand" "r"))]
>    "GET_MODE (operands[0]) == word_mode"
>    "bv%* %%r0(%0)"
>    [(set_attr "type" "branch")
>     (set_attr "length" "4")])
>
> so the C condition depends on operands[], which isn't usually allowed
> for named patterns.  We get away with it at the moment because we only
> test for the existence of HAVE_indirect_jump, not its value:
>
> /* Generate code to indirectly jump to a location given in the rtx LOC.  */
>
> void
> emit_indirect_jump (rtx loc ATTRIBUTE_UNUSED)
> {
> #ifndef HAVE_indirect_jump
>    sorry ("indirect jumps are not available on this target");
> #else
>    struct expand_operand ops[1];
>    create_address_operand (&ops[0], loc);
>    expand_jump_insn (CODE_FOR_indirect_jump, 1, ops);
>    emit_barrier ();
> #endif
> }
>
> but I think testing HAVE_indirect_jump (-> targetm.have_indirect_jump ())
> is more correct.
>
> Would it be OK to remove the operands[] condition?  Or should/could it be a
> pmode_register_operand instead of a register_operand?
>
> Thanks,
> Richard
>
>


-- 
John David Anglin  dave.anglin@bell.net