From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32242 invoked by alias); 22 Sep 2011 15:32:52 -0000 Received: (qmail 32231 invoked by uid 22791); 22 Sep 2011 15:32:51 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-gx0-f175.google.com (HELO mail-gx0-f175.google.com) (209.85.161.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Sep 2011 15:32:37 +0000 Received: by gxk4 with SMTP id 4so2203147gxk.20 for ; Thu, 22 Sep 2011 08:32:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.147.3 with SMTP id z3mr2094325ann.168.1316705557003; Thu, 22 Sep 2011 08:32:37 -0700 (PDT) Received: by 10.100.37.4 with HTTP; Thu, 22 Sep 2011 08:32:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Sep 2011 16:48:00 -0000 Message-ID: Subject: Re: [3/4] SMS: Record moves in the partial schedule From: Ayal Zaks To: Ayal Zaks , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-09/txt/msg01340.txt.bz2 >> Only request is to document that the register moves are >> placed/assigned-id's=A0in 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: > >=A0FOR_EACH_VEC_ELT_REVERSE (ps_reg_move_info, ps->reg_moves, i, move) >=A0 =A0add_insn_before (move->insn, ps_first_note (ps, move->def), NULL); > >and for the prologue/epilogue code. =A0Both 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=A0all regmoves of a node consecutive id's: >=A0=A0=A0=A0=A0=A0=A0=A0=A0 i_reg_moves =3D MIN (i_reg_moves, SCHED_NREG_M= OVES (u)); > >=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* The reg_moves start from the *first* reg_mo= ve backwards.=A0 */ > !=A0=A0=A0=A0=A0=A0=A0 i_reg_move =3D SCHED_FIRST_REG_MOVE (u) + (i_reg_m= oves - 1); Ayal. 2011/9/22 Richard Sandiford > > Ayal Zaks writes: > > Richard Sandiford wrote on 30/08/2011 > > 03:10:50 PM: > > > >> From: Richard Sandiford > >> 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: > >> > >> =A0 - it splits the generation of register moves into two: > > schedule_reg_moves > >> =A0 =A0 records moves in the partial schedule, while apply_reg_moves m= akes > > the > >> =A0 =A0 register substitutions. > >> > >> =A0 =A0 This patch doesn't actually schedule the moves. =A0Instead, th= ere's > >> =A0 =A0 some throw-away code in apply_reg_moves to emit the moves in t= he > >> =A0 =A0 same as we do now. =A0That's throw-away code that will be remo= ved > >> =A0 =A0 in the final patch. > >> > >> =A0 - schedule_reg_moves is allowed to fail. =A0We then try again with= the > >> =A0 =A0 next ii (subject to the usual ii limits). > >> > >> =A0 =A0 In this patch, schedule_reg_moves always returns true. > >> > >> =A0 - The partial schedule uses ids to represent register moves. > >> =A0 =A0 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=A0in 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: > > =A0FOR_EACH_VEC_ELT_REVERSE (ps_reg_move_info, ps->reg_moves, i, move) > =A0 =A0add_insn_before (move->insn, ps_first_note (ps, move->def), NULL); > > and for the prologue/epilogue code. =A0Both 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. =A0If 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. =A0(There's already a fair bit > of info in the structure, but we could add more later if we need it.) > > > Functionality-wise=A0it results in=A0identical code as current version, > > right? > > Yeah, that's right. =A0Only patch 4 does anything useful to the output. > > Richard > >