Movatterモバイル変換


[0]ホーム

URL:


Previous:, Up:Iterators   [Contents][Index]


16.24.5 Parameterized Names

Ports sometimes need to apply iterators using C++ code, in order toget the code or RTL pattern for a specific instruction. For example,suppose we have the ‘neon_vq<absneg><mode>’ pattern given above:

(define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG])(define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")])(define_insn "neon_vq<absneg><mode>"  [(set (match_operand:VDQIW 0 "s_register_operand" "=w")(unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w")       (match_operand:SI 2 "immediate_operand" "i")]      QABSNEG))]  …)

A port might need to generate this pattern for a variable‘QABSNEG’ value and a variable ‘VDQIW’ mode. There are twoways of doing this. The first is to build the rtx for the patterndirectly from C++ code; this is a valid technique and avoids any riskof combinatorial explosion. The second is to prefix the instructionname with the special character ‘@’, which tells GCC to generatethe four additional functions below. In each case,name is thename of the instruction without the leading ‘@’ character,without the ‘<…>’ placeholders, and with any underscorebefore a ‘<…>’ placeholder removed if keeping it wouldlead to a double or trailing underscore.

insn_code maybe_code_for_name (i1,i2, …)

See whether replacing the first ‘<…>’ placeholder withiterator valuei1, the second with iterator valuei2, andso on, gives a valid instruction. Return its code if so, otherwisereturnCODE_FOR_nothing.

insn_code code_for_name (i1,i2, …)

Same, but abort the compiler if the requested instruction does not exist.

rtx maybe_gen_name (i1,i2, …,op0,op1, …)

Check for a valid instruction in the same way asmaybe_code_for_name. If the instruction exists,generate an instance of it using the operand values given byop0,op1, and so on, otherwise return null.

rtx gen_name (i1,i2, …,op0,op1, …)

Same, but abort the compiler if the requested instruction does not exist,or if the instruction generator invoked theFAIL macro.

For example, changing the pattern above to:

(define_insn "@neon_vq<absneg><mode>"  [(set (match_operand:VDQIW 0 "s_register_operand" "=w")(unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w")       (match_operand:SI 2 "immediate_operand" "i")]      QABSNEG))]  …)

would define the same patterns as before, but in addition would generatethe four functions below:

insn_code maybe_code_for_neon_vq (int, machine_mode);insn_code code_for_neon_vq (int, machine_mode);rtx maybe_gen_neon_vq (int, machine_mode, rtx, rtx, rtx);rtx gen_neon_vq (int, machine_mode, rtx, rtx, rtx);

Calling ‘code_for_neon_vq (UNSPEC_VQABS, V8QImode)’would then giveCODE_FOR_neon_vqabsv8qi.

It is possible to have multiple ‘@’ patterns with the samename and same types of iterator. For example:

(define_insn "@some_arithmetic_op<mode>"  [(set (match_operand:INTEGER_MODES 0 "register_operand") …)]  …)(define_insn "@some_arithmetic_op<mode>"  [(set (match_operand:FLOAT_MODES 0 "register_operand") …)]  …)

would produce a single set of functions that handles bothINTEGER_MODES andFLOAT_MODES.

It is also possible for these ‘@’ patterns to have differentnumbers of operands from each other. For example, patterns witha binary rtl code might take three operands (one output and two inputs)while patterns with a ternary rtl code might take four operands (oneoutput and three inputs). This combination would produce separate‘maybe_gen_name’ and ‘gen_name’ functions foreach operand count, but it would still produce a single‘maybe_code_for_name’ and a single ‘code_for_name’.

Currently, these@ patterns only take into account patterns forwhich nodefine_subst has been applied (seeRTL Templates Transformations).Any ‘<…>’ placeholders that refer to subst attributes(seeSubst Iterators) are ignored.


Previous:Subst Iterators, Up:Iterators   [Contents][Index]


[8]ページ先頭

©2009-2026 Movatter.jp