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 E489A3858D37 for ; Wed, 2 Feb 2022 23:22:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E489A3858D37 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 212NLWiW004107; Wed, 2 Feb 2022 17:21:32 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 212NLV5n004106; Wed, 2 Feb 2022 17:21:31 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 2 Feb 2022 17:21:31 -0600 From: Segher Boessenkool To: Bill Schmidt Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com Subject: Re: [PATCH 6/8] rs6000: Remove -m[no-]fold-gimple flag [PR103686] Message-ID: <20220202232131.GB614@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-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, 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: Wed, 02 Feb 2022 23:22:35 -0000 On Fri, Jan 28, 2022 at 11:50:24AM -0600, Bill Schmidt wrote: > The -m[no-]fold-gimple flag was really intended primarily for internal > testing while implementing GIMPLE folding for rs6000 vector built-in > functions. It ended up leaking into other places, causing problems such > as PR103686 identifies. Let's remove it. Okay. BUT: > gcc.target/powerpc/builtins-1.c was more problematic. It was written in > such a way as to be extremely fragile. For this one, I rewrote the whole > test in a different style, using individual functions to test each > built-in function. These same tests are also largely covered by > builtins-1-be-folded.c and builtins-1-le-folded.c, so I chose to > explicitly make this test -mbig for simplicity, and use -O2 for clean code > generation. I made some slight modifications to the expected instruction > counts as a result, and tested on both 32- and 64-bit. This made the testsuite part very hard to review again. I gave up. In the future, please do *one* logical change per patch. That way at least the patches are readable (they were not now, a lot of mixed-up context). So first a patch rewriting this testcase, and then a separate patch that is the meat of *this* patch. > Most instruction > count tests now use the {\m ... \M} style, but I wasn't able to figure out > how to get this right for vcmpequd. and vcmpgtud. Using \. didn't do the > trick, and I got tired of messing with it. I can change those if you > suggest the proper incantation for an opcode ending with a period. {\madd\.} does the trick. \.\M does not make any sense (a word cannot end in a dot, it cannot contain one in the first place). \M\. is valid, but add\M\. is a bit silly: it is obvious the word ends there, there is no need to assert that :-) Okay for trunk like that. Thanks! Segher