Jeff Law <jeffreya...@gmail.com> writes: > 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?
I don't think there should be any compile-time impact, and I can't measure one when compiling fold-const.ii -O0 (my go-to test for this). The md interface remains the same, in that all interaction is via the the operands[] array. Any writes to the individual operandN variables (where present) are ignored both before and after the patch. However, I suppose this does make it possible to turn the operandN arguments into constants, to prevent accidents. I'll try that. Thanks, Richard
