>> +(define_expand "riscv_arcv_apex_void_ftype_src0_v"
>> + [(unspec_volatile [(match_operand:SI 0 "const_int_operand")
>> + (match_operand 1 "nonmemory_operand")]
>> + UNSPEC_ARCV_APEX_VOID_SRC0_V)]
>> + ""
>> +{
>> + emit_insn (gen_rtx_UNSPEC_VOLATILE (VOIDmode,
>> + gen_rtvec (2, operands[0],
>> + operands[1]),
>> + UNSPEC_ARCV_APEX_VOID_SRC0_V));
>> + DONE;
>> +})
>You only some think like this since it's same as what you emit via emit_insn
>unless I'm mistaken?
> (define_expand "riscv_arcv_apex_void_ftype_src0_v"
> [(unspec_volatile [(match_operand:SI 0 "const_int_operand")
> (match_operand 1 "nonmemory_operand")]
> UNSPEC_ARCV_APEX_VOID_SRC0_V)]
> ""
>{
>})
>And same for all other define_expand pattern
Thanks for the suggestion! I tried simplifying to an empty body, but it
fails with "unrecognizable insn" during expansion.
The define_insn patterns (e.g., riscv_arcv_apex_void_ftype_<APEX_SRC0:mode>_v)
use mode iterators to generate all type combinations (SI, DI, etc.). The
define_expand provides one expander name to the registered builtin (e.g.,
riscv_arcv_apex_void_ftype_src0_v) that handles all these combinations -
otherwise
I'd need to know the operand types upfront to select the correct define_insn
pattern.
The explicit emit_insn constructs the RTL with the actual operand modes
(via GET_MODE), allowing the UNSPEC to route to the correct mode-specific
pattern. Without it, the pattern matching fails.
