From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id EDF6F383982E for ; Fri, 8 Apr 2022 14:35:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EDF6F383982E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 238EYKK7007184; Fri, 8 Apr 2022 09:34:20 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 238EYJOI007182; Fri, 8 Apr 2022 09:34:19 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 8 Apr 2022 09:34:19 -0500 From: Segher Boessenkool To: "Kewen.Lin" Cc: will schmidt , GCC Patches , Peter Bergner , Bill Schmidt , David Edelsohn Subject: Re: [PATCH] rs6000/test: Adjust p9-vec-length-7 sensitive to unroll [PR103196] Message-ID: <20220408143419.GR614@gate.crashing.org> References: <1cc2e963-b189-4dde-e7cd-b6a97162afe2@linux.ibm.com> <78a4eeaa9107394d8dd60efb56b02481bcac99ee.camel@vnet.ibm.com> <20220407192945.GO614@gate.crashing.org> 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-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 14:35:22 -0000 Hi! Thanks for investigating. On Fri, Apr 08, 2022 at 03:25:51PM +0800, Kewen.Lin wrote: > on 2022/4/8 3:29 AM, Segher Boessenkool wrote: > > On Thu, Apr 07, 2022 at 09:19:51AM -0500, will schmidt wrote: > >> On Mon, 2022-02-28 at 13:37 +0800, Kewen.Lin via Gcc-patches wrote: > >>> As PR103196 shows, p9-vec-length-full-7.c needs to be adjusted as the > >>> complete unrolling can happen on some of its loops. This patch is to > >>> use pragma "GCC unroll 0" to disable all possible loop unrollings. > >>> Hope it can help the case not that fragile. > >> > >> ok > >> > >> Is the lack of effectiveness of "-fno-unroll-loops" otherwise > >> understood, or is there further issue behind that option? > > > > There is -fpeel-loops as well, and cunroll is independent of all of > > these as well? > > Yes, kind of. As below code, unroll-loops and peel-loops only affect > whether it's acceptable to grow size. > > /* Allow cunroll to grow size accordingly. */ > if (!opts_set->x_flag_cunroll_grow_size) > opts->x_flag_cunroll_grow_size > = (opts->x_flag_unroll_loops > || opts->x_flag_peel_loops > || opts->x_optimize >= 3); > > This flag_cunroll_grow_size doesn't gate the pass, it's only for > "may_increase_size". Yuck. > unsigned int val = tree_unroll_loops_completely (flag_cunroll_grow_size, > true); > > The cunroll still can take effect if its transformation doesn't grow > size even if we specify -fno-unroll-loops and -fno-peel-loops. Yeah. And the pragma disables it, so we really should have a command line option that does the same (but globally), too. > >> I would > >> expect the effect of the option, versus the pragma, two to roughly > >> equivalent. Obviously it is not. :-) > > > > Yes, me too. And I do not see what makes the difference, if it isn't > > the peel thing :-( > > > > Ke Wen, can you try with -fno-peel-loops please? > > I had a try and it didn't help as the cunroll pass doesn't grow size > for this case. By the way, -fdisable-tree-cunroll does work. But I > thought using pragma looks better as it's not an internal thing like > the disabling option and I also expect other future unrolling related > changes would respect it. > > Do you also prefer pragma, or want that disabling option? That flag please. And we should have a -fno-unroll that disables all separate kinds of unrolling, imo -- but that is a separate problem, not something to hold up your patch for. Okay for trunk without the pragma. Thanks! (The pragma is a good solution if you want to disable unrolling for a very specific piece of code only, which is not the case here: the problem currently shows up in one place, but it could happen elsewhere!) Segher