This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, SMS] Support instructions with REG_INC_NOTE (re-submisson)


Ok, so this?extends the infrastructure to support insns?which set an
arbitrary number of?registers, but currently specifically handles only
REG_INC situations (which set two registers). I'm not against
{0,1,infinity}, but wonder if this case really deserves the
complexity: post/pre-inc/decrementing load insns may need regmoves for
the register loaded, due to the latency of the load and desire to
schedule associated uses farther than ii cycles away (as do regular
loads), but do they also?need regmoves for?the address register being
post/pre-inc/decremented? Its latency should not be long, and it's
often feeding only itself so regmoves are not needed/won't help. If
not, perhaps a simpler solution is to allow REG_INC insns but disallow
their address register from being regmove'd, dedicating?the single
regmove info for the value loaded.

Are there actually cases where you need the address register?to regmove?

Ayal.

2011/8/15 Revital Eres <revital.eres@linaro.org>
>
> Hello,
>
> This is a re-submission of the patch to support instructions with REG_INC_NOTE.
> (http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01309.html)
>
> It contains a minor change from the previous submission suggested by
> Richard Sandiford: to use reg_referenced_p instead of
> rtx_referenced_p.
>
> The patch supports instructions with auto inc/dec operations as to
> support such instructions we can not assume that there is only one
> definition in the instruction. This assumption is currently used to
> generate reg-moves information. Because the auto inc/dec instruction
> defines more then one register we need to generate different reg-moves
> for each of the definitions. At some point in the SMS procedure we
> need to find
> the first reg-move generated for a specific definition(*) and if there
> is more than one definition in the instruction (lets call it insn1)
> we can not simply assume it's first reg-move instruction is the first
> instruction right before insn1.
>
> for example, the following instruction defines two variables: x and i:
> x = mem [POST_INC (i)]
>
> lets say both of them need reg-move
>
> insn 1) reg_move_i = i
> insn 2) reg_move_x = x
> insn 3) x = mem [POST_INC (i)]
>
> then in order to reach the first reg-move of i we can not just go to
> insn 2 like in the current implementation, so we need to save for each
> definition in the instruction it's first reg-move instruction.
>
> (*) I'm referring to the generation of prologue and epilogue
> (duplicate_insns_of_cycles) which uses first_reg_move field in
> node_sched_params structure, and SCHED_FIRST_REG_MOVE definition in
> modulo-sched.c.
>
> Reg-tested and bootstrap on ppc64-redhat-linux enabling SMS on loops with SC 1.
>
> OK for mainline?
>
> Thanks,
> Revital
>
>
> ? ? ? ?* modulo-sched.c (record_inc_dec_insn_info,
> ? ? ? ?free_node_sched_params): New functions.
> ? ? ? ?(SCHED_FIRST_REG_MOVE, SCHED_NREG_MOVES): Remove.
> ? ? ? ?(struct regmove_info): New.
> ? ? ? ?(insn_regmove_info): New field in node_sched_params.
> ? ? ? ?(print_node_sched_params): Print information for all the
> ? ? ? ?definitions in the instructions.
> ? ? ? ?(generate_reg_moves, duplicate_insns_of_cycles,
> ? ? ? ?set_node_sched_params): Adjust the code to handle instructions
> ? ? ? ?that have multiple definitions.
> ? ? ? ?(sms_schedule): Handle loops that contain instructions with
> ? ? ? ?FIND_REG_INC_NOTE and call free_node_sched_params.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]