This is the mail archive of the
mailing list for the GCC project.
Re: pa indirect_jump instruction
- From: John David Anglin <dave dot anglin at bell dot net>
- To: gcc at gcc dot gnu dot org, law at redhat dot com, rdsandiford at googlemail dot com
- Date: Tue, 30 Jun 2015 17:27:16 -0400
- Subject: Re: pa indirect_jump instruction
- Authentication-results: sourceware.org; auth=none
- References: <87egks2a0k dot fsf at googlemail dot com>
I would think pmode_register_operand is correct. Then, condition can be
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...
[(set (pc) (match_operand 0 "register_operand" "r"))]
"GET_MODE (operands) == word_mode"
[(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)
sorry ("indirect jumps are not available on this target");
struct expand_operand ops;
create_address_operand (&ops, loc);
expand_jump_insn (CODE_FOR_indirect_jump, 1, ops);
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?
John David Anglin firstname.lastname@example.org