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