From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68403 invoked by alias); 7 Feb 2020 16:41:19 -0000 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 Received: (qmail 68394 invoked by uid 89); 7 Feb 2020 16:41:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=meaningful X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Feb 2020 16:41:18 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 017GfFfQ028949; Fri, 7 Feb 2020 10:41:16 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 017GfF4C028947; Fri, 7 Feb 2020 10:41:15 -0600 Date: Fri, 07 Feb 2020 16:41:00 -0000 From: Segher Boessenkool To: Uros Bizjak Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] Improve splitX passes management Message-ID: <20200207164115.GR22482@gate.crashing.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00449.txt.bz2 On Thu, Feb 06, 2020 at 12:13:35PM +0100, Uros Bizjak wrote: > The names of split_before_sched2 ("split4") and split_before_regstack > ("split3") do not reflect their insertion point in the sequence of passes, > where split_before_regstack follows split_before_sched2. Reorder the code > and rename the passes to reflect the reality. Renaming them to other splitN doesn't help much :-/ Having stable names is more important (some archs actually use these names), I'd say. But it's hard to come up with shortish more meaningful names. There is no real need for the N in splitN to be in order, but sure it can be surprising otherwise. > +bool > +pass_split_before_regstack::gate (function *) > +{ > +#if HAVE_ATTR_length && defined (STACK_REGS) > + /* If flow2 creates new instructions which need splitting > + and scheduling after reload is not done, they might not be > + split until final which doesn't allow splitting > + if HAVE_ATTR_length. */ > + return !enable_split_before_sched2 (); > +#else > + return false; > +#endif > +} flow.c was deleted in 2006... Is this split still needed at all? If so, change the comment please? :-) Segher