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 7465B3858D3C for ; Sun, 27 Nov 2022 18:17:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7465B3858D3C 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 2ARIGS4V014338; Sun, 27 Nov 2022 12:16:28 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2ARIGRUE014337; Sun, 27 Nov 2022 12:16:27 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Sun, 27 Nov 2022 12:16:27 -0600 From: Segher Boessenkool To: "Kewen.Lin" Cc: GCC Patches , David Edelsohn , Peter Bergner , Michael Meissner Subject: Re: [PATCH 1/2] rs6000: Emit vector fp comparison directly in rs6000_emit_vector_compare Message-ID: <20221127181627.GL25951@gate.crashing.org> References: <20221116184437.GW25951@gate.crashing.org> <30553cb3-35d0-c51b-ffc4-0f8a320bd1ed@linux.ibm.com> <20221118151030.GA25951@gate.crashing.org> <7ccd6eda-8d29-8e41-6e9f-041097eee42e@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ccd6eda-8d29-8e41-6e9f-041097eee42e@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi! Whoops I missed following up to this. On Mon, Nov 21, 2022 at 10:01:14AM +0800, Kewen.Lin wrote: > on 2022/11/18 23:10, Segher Boessenkool wrote: > > ge is nasty for float, it means something different with and without > > -ffast-math (with fast-math ge means not lt, le means not gt; both can > > be done with a simple single condition, no cror needed. (Compare to ne > > which is the same with and without -ffast-math, that is because it has a > > "not" in its definition!) > > It's true for scalar float comparison, but the context here is for vector > comparison, the result of comparison is still vector (of boolean), and we > have the corresponding vector comparison instruction for ge, so I think it > should be fine here. It is fine if all contexts it is used in allow ge insns, sure. But you have to make sure that is true; ge still is nasty, it truly means something different with fastmath (which applies to vector float just\ the same as it does to scalar float). > > Thanks for the explanation! > > > > Can you do this in multiple steps, which will make it much easier to > > review, and to spot the problem if some unexpected problem shows up? > > Sure, I'll try my best to separate it into some steps and show how it > evolves gradually. If you can make the bulk of the series not actually change code generation, just rearrange and massage the compiler code, that is much easier to review (and it also helps to spot the problems in if there are regressions, as a bonus). Cheers, Segher