From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22255 invoked by alias); 11 Oct 2011 08:18:17 -0000 Received: (qmail 22234 invoked by uid 22791); 11 Oct 2011 08:18:11 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,TW_DD X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 Oct 2011 08:17:46 +0000 Received: by wwf10 with SMTP id 10so8508289wwf.8 for ; Tue, 11 Oct 2011 01:17:44 -0700 (PDT) Received: by 10.216.134.106 with SMTP id r84mr8199819wei.30.1318321064655; Tue, 11 Oct 2011 01:17:44 -0700 (PDT) Received: from richards-thinkpad.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice2n1.emea.ibm.com. [195.212.29.75]) by mx.google.com with ESMTPS id l9sm37163734wba.5.2011.10.11.01.17.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 01:17:42 -0700 (PDT) From: Richard Sandiford To: Ayal Zaks Mail-Followup-To: Ayal Zaks ,gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Cc: gcc-patches@gcc.gnu.org Subject: Re: [4/4] Make SMS schedule register moves References: <87litguw08.fsf@firetop.home> Date: Tue, 11 Oct 2011 08:49:00 -0000 In-Reply-To: (Ayal Zaks's message of "Mon, 10 Oct 2011 17:42:38 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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-10/txt/msg00854.txt.bz2 Ayal Zaks writes: >>> The issue of assigning stages to reg-moves is mostly relevant for >>> prolog and epilog generation, which requires and receives special >>> attention -- handled very nicely by ps_num_consecutive_stages! Note >>> that currently a simple boolean indicator for (the exceptional case >>> of) double stages would suffice, instead of generalizing to arbitrary >>> nums of consecutive stages (see any potential use for them?). >> >> Not in the immediate term. =C2=A0But I think having a boolean indicator >> would be inconsistent. =C2=A0If the distance field is an int (even though >> we only expect distance-0 and distance-1 register dependencies) >> then I think the number of stages should be too. >> >> I did wonder originally about using a boolean, but IMO, it makes >> the code less readable rather than more. =C2=A0Instead of a simple >> range check like: >> >> =C2=A0 =C2=A0 if (first_stage_for_insn <=3D last_stage_in_range >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 && last_stage_for_insn >=3D first_stage_in_r= ange) >> >> we end up with the equivalent of: >> >> =C2=A0 =C2=A0 if (first_stage_for_insn <=3D last_stage_in_range >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 && (double_stage_move_p (...) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ? first_stage_for_insn + 1 >= =3D first_stage_in_range >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : first_stage_for_insn >=3D fi= rst_stage_in_range)) >> >> with no corresponding simplification elsewhere. >> > > Sure. But setting the range can be done by consulting an simple > indicator, rather than generalizing to arbitrary stage numbers; e.g.: > > +ps_num_consecutive_stages (partial_schedule_ptr ps, int id) > +{ > + if (id >=3D ps->g->num_nodes && ps_reg_move (ps, id)->double_stages) > + return 2; > + else > + return 1; > +} > > or > > - last_u =3D first_u + ps_num_consecutive_stages (ps, u) - 1; > + if (...double_stages) last_u =3D first_u + 1; > + else last_u =3D first_u; Understood. I still prefer the posted version though. >> E.g. adding something like this at the end: >> >> =C2=A0 ??? The algorithm restricts the scheduling window to II cycles. >> =C2=A0 In rare cases, it may be better to allow windows of II+1 cycles. >> =C2=A0 The window would then start and end on the same row, but with >> =C2=A0 different "must precede" and "must follow" requirements. >> >> Let me know what you think and I'll add it as a follow-on patch. >> > > great, thanks. OK, added with the patch below. >>>> + >>>> + =C2=A0 The move is part of a chain that satisfies register dependenc= ies >>>> + =C2=A0 between a producing ddg node and various consuming ddg nodes. >>>> + =C2=A0 If some of these dependencies cross a loop iteration (that is, >>>> + =C2=A0 have a distance of 1) then DISTANCE1_USES is nonnull and cont= ains >>>> + =C2=A0 the set of uses with distance-1 dependencies. =C2=A0DISTANCE1= _USES >>>> + =C2=A0 is null otherwise. >>>> + >>> >>> Maybe clarify that they are upwards-exposed or live-in uses. >> >> OK, changed to: >> >> =C2=A0 The move is part of a chain that satisfies register dependencies >> =C2=A0 between a producing ddg node and various consuming ddg nodes. >> =C2=A0 If some of these dependencies have a distance of 1 (meaning that >> =C2=A0 the use is upward-exposoed) then DISTANCE1_USES is nonnull and > > exposed (typo) Oops, also fixed below (and applied). Richard gcc/ * modulo-sched.c: Fix comment typo. Mention the possibility of using scheduling windows of II+1 cycles. Index: gcc/modulo-sched.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- gcc/modulo-sched.c 2011-10-10 12:42:41.000000000 +0100 +++ gcc/modulo-sched.c 2011-10-11 09:07:08.069166743 +0100 @@ -545,7 +545,7 @@ set_columns_for_ps (partial_schedule_ptr The move is part of a chain that satisfies register dependencies between a producing ddg node and various consuming ddg nodes. If some of these dependencies have a distance of 1 (meaning that - the use is upward-exposoed) then DISTANCE1_USES is nonnull and + the use is upward-exposed) then DISTANCE1_USES is nonnull and contains the set of uses with distance-1 dependencies. DISTANCE1_USES is null otherwise. =20 @@ -1810,7 +1810,11 @@ sms_schedule (void) 41. endif 42. compute epilogue & prologue 43. finish - succeeded to schedule -*/ + + ??? The algorithm restricts the scheduling window to II cycles. + In rare cases, it may be better to allow windows of II+1 cycles. + The window would then start and end on the same row, but with + different "must precede" and "must follow" requirements. */ =20 /* A limit on the number of cycles that resource conflicts can span. ??? = Should be provided by DFA, and be dependent on the type of insn scheduled. Cu= rrently