On 5/19/25 3:16 AM, Richard Sandiford wrote:
Richard Sandiford <richard.sandif...@arm.com> writes:
Jeff Law <jeffreya...@gmail.com> 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 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.
The only problem case seemed to be sparc.md, which uses operandN
variables in code that always invokes DONE:
(define_expand "zero_extendhisi2"
[(set (match_operand:SI 0 "register_operand" "")
(zero_extend:SI (match_operand:HI 1 "register_operand" "")))]
""
{
rtx temp = gen_reg_rtx (SImode);
rtx shift_16 = GEN_INT (16);
int op1_subbyte = 0;
if (GET_CODE (operand1) == SUBREG)
{
op1_subbyte = SUBREG_BYTE (operand1);
op1_subbyte /= GET_MODE_SIZE (SImode);
op1_subbyte *= GET_MODE_SIZE (SImode);
operand1 = XEXP (operand1, 0);
}
emit_insn (gen_ashlsi3 (temp, gen_rtx_SUBREG (SImode, operand1, op1_subbyte),
shift_16));
emit_insn (gen_lshrsi3 (operand0, temp, shift_16));
DONE;
})
So I suppose the question is whether we want to continue to allow that,
or whether it would be better to flag accidental writes to operandN
instead of operands[N] for code that doesn't invoke DONE.
Given how long it's taken when I've had to track this kind of thing down
(out of tree port) I'd say let's not allow it ;-) If the above is the
only known active instance in tree, let's fix and never have to think
about that problem again.
Jeff
Richard
