Denis Chertykov schrieb:
> 2011/10/18 Georg-Johann Lay <a...@gjlay.de>:
>> This patch do some tweaks to addhi3 like adding QI scratch register.
>>
>> The original *addhi3 insn is still there and located prior to new
>> addhi3_clobber insn because addhi3 is special to reload (thanks Danis for 
>> this
>> note) so that there is a version with and a version without scratch register.
>>
>> Patch passes without regressions.
>>
> 
> Which improvements added by this patch ?
> 
> Denis.

If the addhi3 is expanded early, the addition happens with QI scratch which
avoids reload of constant if target register is in NO_LD. And reduce register
pressure as only QI is needed and not reload of constant to HI.

Otherwise, there might be sequences like

ldi r31, 2    ; *reload_inhi
mov r12, r31
clr r13

add r14, r12  ; *addhi3
adc r15, r13

which now will be

ldi r31, 2    ; addhi3_clobber
add r14, r31
adc r15, __zero_reg__

Similar applies if the reload of the constant happens to LD regs:

ldi r30, 2    ; *movhi
clr r31

add r14, r12  ; *addhi3
adc r15, r13

will become

ldi r30, 2    ; addhi3_clobber
add r14, r30
adc r15, __zero_reg__

For *addhi3 insns the register pressure is not reduced but the insn sequence
might be smarter if peep2 comes up with a QI scratch or if it detects a
*reload_inhi insn just prior to the addition (and the reg that holds the
reloaded constant dies after the addition).

As *addhi3 is special to reload, there is still an "ordinary" add addhi insn
without scratch. This is easier because, e.g. prologue and epilogue generation
generate add insns (not by means of addhi3 expander but by explicit
gan_rtx_PLUS). Yet the addhi3 expander factors out the situations when an
addhi3 insn is to be generated via addhi3 expander late in the compilation 
process.

Johann

Reply via email to