On 5/19/25 3:16 AM, Richard Sandiford wrote:
Richard Sandiford writes:
Jeff Law writes:
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 suc
On 5/18/25 2:24 PM, Richard Sandiford wrote:
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 o
Richard Sandiford writes:
> Jeff Law writes:
>> 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 an
Jeff Law 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 an
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 p
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++ p
