On 09/04/14 08:15, Jiong Wang wrote:
currently, the instruction sink in "prepare_shrink_wrap" is a bit
conservative
that some further optimization opportunities have been missed.
given the prologue use register A by:
(store A, [sp + offset])
then given the entry_basic_block contains a simply register copy like:
(move A, B)
current "prepare_shrink_wrap" will sink the move instruction as deep as
it can,
then the entry_basic_block could be marked as "don't need prologue".
while if we replace "(move A, B)" into either one of
* "(move B, CONST_K)",
* "(move B, (plus A, CONST_K))"
we still could do the same sink optimization, but *current gcc do not*.
pattern like (move B, CONST_K) are very normal for some RISC targets.
for example on AArch64, we could have the following pair:
adrp x22, global_data_a
add x0, x22, :lo12:global_data_a
if "adrp" be scheduled into the entry_basic_block then the write of x22 may
prevent shrink-wrap happen.
when judge whether one instruction is sink-able,
move_insn_for_shrink_wrap only
accept simply reg copy that both dest and src are REG_P, while the second
operand of adrp is actually a SYMBOL_REF, thus it's reject by the
optimization.
this patch relax the restriction on src to accept any one of the following:
+ REG
+ CONST_OBJ, like SYMBOL_REF
+ combination of single REG and any other CONST_OBJs.
(reg def/use calculation will not affected by CONST_OBJs)
RISC backend may benefit more from this relax, although there still
be minor improvements on x86. for example, there are 17 more functions
shrink-wrapped during x86-64 bootstrap, like sort_bucket in ira-color.c.
test done
=========
no regression on aarch64-none-elf bare-metal.
no regression on x86-64 check-gcc.
both aarch64 and x86-64 bootstrap OK.
ok for install?
2014-09-04 Jiong Wang<jiong.w...@arm.com>
gcc/
* shrink-wrap.c (rtx_search_arg): New structure type.
(rtx_search_arg_p): New typedef.
(count_reg_const): New callback function.
(move_insn_for_shrink_wrap): Relax the restriction on src operand.
Conceptually OK. Some questions/concerns about the implementation.
It seems to me that what you're trying to describe on the RHS is
REG_P || CONSTANT_P
Note that CONSTANT_P will catch things like (high (symbol_ref)) and
(lo_sum (reg) (symbol_ref)) which are often used to build addresses on
some targets.
With that in mind, rather than using a for_each_rtx callback, test
if (REG_P (src) || CONSTANT_P (src))
Note that SRC, when it is a CONSTANT_P, may have a variety of forms
with embedded registers. You'll need to verify that all of those
registers are not assigned after the insn with the CONSTANT_P source
operand. Right now you only perform that check when SRC is a REG_P.
Jeff
