This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

pa indirect_jump instruction

I have a series of patches to convert all non-optab instructions to
the target-insns.def interface. 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.  */

emit_indirect_jump (rtx loc ATTRIBUTE_UNUSED)
#ifndef HAVE_indirect_jump
  sorry ("indirect jumps are not available on this target");
  struct expand_operand ops[1];
  create_address_operand (&ops[0], loc);
  expand_jump_insn (CODE_FOR_indirect_jump, 1, ops);
  emit_barrier ();

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]