From patchwork Tue Oct 11 08:17:41 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 118880 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 404E7B6F6F for ; Tue, 11 Oct 2011 19:18:26 +1100 (EST) 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 09:17:41 +0100 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 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org 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.  But I think having a boolean indicator >> would be inconsistent.  If 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.  Instead of a simple >> range check like: >> >>     if (first_stage_for_insn <= last_stage_in_range >>         && last_stage_for_insn >= first_stage_in_range) >> >> we end up with the equivalent of: >> >>     if (first_stage_for_insn <= last_stage_in_range >>         && (double_stage_move_p (...) >>             ? first_stage_for_insn + 1 >= first_stage_in_range >>             : first_stage_for_insn >= first_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 >= ps->g->num_nodes && ps_reg_move (ps, id)->double_stages) > + return 2; > + else > + return 1; > +} > > or > > - last_u = first_u + ps_num_consecutive_stages (ps, u) - 1; > + if (...double_stages) last_u = first_u + 1; > + else last_u = first_u; Understood. I still prefer the posted version though. >> E.g. adding something like this at the end: >> >>   ??? 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. >> >> Let me know what you think and I'll add it as a follow-on patch. >> > > great, thanks. OK, added with the patch below. >>>> + >>>> +   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 cross a loop iteration (that is, >>>> +   have a distance of 1) then DISTANCE1_USES is nonnull and contains >>>> +   the set of uses with distance-1 dependencies.  DISTANCE1_USES >>>> +   is null otherwise. >>>> + >>> >>> Maybe clarify that they are upwards-exposed or live-in uses. >> >> OK, changed to: >> >>   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 > > 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 =================================================================== --- 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. @@ -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. */ /* 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. Currently