>> Only request is to document that the register moves are >> placed/assigned-id's in a specific order. > >I suppose this is the downside of splitting the patches up, sorry, >but the ids are only ordered for the throw-away loop: > > FOR_EACH_VEC_ELT_REVERSE (ps_reg_move_info, ps->reg_moves, i, move) > add_insn_before (move->insn, ps_first_note (ps, move->def), NULL); > >and for the prologue/epilogue code. Both are replaced in patch 4 >with code that doesn't rely on the ordering of ids. Ok then, very well. I was mostly referring to the following in prologue/epiloque code, which merely relies on assigning all regmoves of a node consecutive id's:
> i_reg_moves = MIN (i_reg_moves, SCHED_NREG_MOVES (u)); > > /* The reg_moves start from the *first* reg_move backwards. */ > ! i_reg_move = SCHED_FIRST_REG_MOVE (u) + (i_reg_moves - 1); Ayal. 2011/9/22 Richard Sandiford <richard.sandif...@linaro.org> > > Ayal Zaks <ayal.z...@gmail.com> writes: > > Richard Sandiford <richard.sandif...@linaro.org> wrote on 30/08/2011 > > 03:10:50 PM: > > > >> From: Richard Sandiford <richard.sandif...@linaro.org> > >> To: gcc-patches@gcc.gnu.org > >> Cc: Ayal Zaks/Haifa/IBM@IBMIL > >> Date: 30/08/2011 03:10 PM > >> Subject: [3/4] SMS: Record moves in the partial schedule > > > >> > >> This patch adds infrastructure that will be used by the final patch. > >> Specifically: > >> > >> - it splits the generation of register moves into two: > > schedule_reg_moves > >> records moves in the partial schedule, while apply_reg_moves makes > > the > >> register substitutions. > >> > >> This patch doesn't actually schedule the moves. Instead, there's > >> some throw-away code in apply_reg_moves to emit the moves in the > >> same as we do now. That's throw-away code that will be removed > >> in the final patch. > >> > >> - schedule_reg_moves is allowed to fail. We then try again with the > >> next ii (subject to the usual ii limits). > >> > >> In this patch, schedule_reg_moves always returns true. > >> > >> - The partial schedule uses ids to represent register moves. > >> The first register move has id g->num_nodes. > >> > >> Richard > > This is fine. > > Thanks. > > > Only request is to document that the register moves are > > placed/assigned-id's in a specific order. > > I suppose this is the downside of splitting the patches up, sorry, > but the ids are only ordered for the throw-away loop: > > FOR_EACH_VEC_ELT_REVERSE (ps_reg_move_info, ps->reg_moves, i, move) > add_insn_before (move->insn, ps_first_note (ps, move->def), NULL); > > and for the prologue/epilogue code. Both are replaced in patch 4 > with code that doesn't rely on the ordering of ids. > > I'd rather the code didn't rely on any ordering here. If any future > code is added that needs to know more about the moves, I think it should > use the move structure instead of the ids. (There's already a fair bit > of info in the structure, but we could add more later if we need it.) > > > Functionality-wise it results in identical code as current version, > > right? > > Yeah, that's right. Only patch 4 does anything useful to the output. > > Richard > >
