Richard Sandiford <[email protected]> writes:
> Jeff Law <[email protected]> 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.
Richard
