On 5/16/25 11:21 AM, Richard Sandiford wrote:
One slightly awkward part about emitting the generator function
bodies is that:
* define_insn and define_expand routines have a separate argument for
each operand, named "operand0" upwards.
* define_split and define_peephole2 routines take a pointer to an array,
named "operands".
* the C++ preparation code for expands, splits and peephole2s uses an
array called "operands" to refer to the operands.
* the automatically-generated code uses individual "operand<N>"
variables to refer to the operands.
So define_expands have to store the incoming arguments into an operands
array before the md file's C++ code, then copy the operands array back
to the individual variables before the automatically-generated code.
splits and peephole2s have to copy the incoming operands array to
individual variables after the md file's C++ code, creating more
local variables that are live across calls to rtx_alloc.
This patch tries to simplify things by making the whole function
body use the operands array in preference to individual variables.
define_insns and define_expands store their arguments to the array
on entry.
This would have pros and cons on its own, but having a single array
helps with future efforts to reduce the duplication between gen_*
functions.
Doing this tripped a warning in stormy16.md about writing beyond
the end of the array. The negsi2 C++ code writes to operands[2]
even though the pattern has no operand 2.
gcc/
* genemit.cc (gen_rtx_scratch, gen_exp): Use operands[%d] rather than
operand%d.
(start_gen_insn): Store the incoming arguments to an operands array.
(gen_expand, gen_split): Remove copies into and out of the operands
array.
* config/stormy16/stormy16.md (negsi): Remove redundant assignment.
So two questions. Is there any meanginful performance impact expected
here using the array form rather than locals? And does this impact how
folks write their C/C++ fragments in the expanders and such?
Jeff
