From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) by sourceware.org (Postfix) with ESMTPS id 3B0B73887006 for ; Wed, 8 Apr 2020 00:50:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3B0B73887006 Received: by mail-pl1-x642.google.com with SMTP id h11so1872926plr.11 for ; Tue, 07 Apr 2020 17:50:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mvJSAj49neVB09tpv/3oX1nvR8P8W7IAMVyESGPAqrQ=; b=qd1XGVbhHMp2ShTAYxYv3324F5xw1Y/CjQyF1BpENS4sdzglZdute7tvpePikxJbS0 nrWbNSKCvQdepy+Ws/FwB5Z7ezIDRGW9WonXkR63y1ZUJsEmKzrYLhEwKr1dtY4eKm3x me9PmKe7YHj2rZE218HdN4VWW4NHfAUfdsAm44fEvnNURbSmjhuRV8RnJPwXoyvokcFg tzVf7GV7+TZTZwnwL0vRg0MTxD/3yNyoo4dSIThZC/HJN5VJbPZH08SOQtssQEZAdjvq GU7RMEPlhPqD9QUFG42kUNJDPg49grywuKQvywsZsJCBQ5jZr53jSar+vl9dZ6GYz8yK vURA== X-Gm-Message-State: AGi0Pubvf3SGfGY8WE3GHpHHKPS9PNoHJY6jvFofE4tQUMsV/3ETE3R2 z6cx15InzhY2l1VOLy7XJtKSbQ== X-Google-Smtp-Source: APiQypJmM+8qsWBS4cceDBgd9JoLn7vRPcLFPKGDpsXIi+0+zx6WMHARRu4nDMODB+ZDPA9gjDK9cw== X-Received: by 2002:a17:902:8a8f:: with SMTP id p15mr4872080plo.45.1586307041163; Tue, 07 Apr 2020 17:50:41 -0700 (PDT) Received: from [192.168.1.11] (174-21-149-226.tukw.qwest.net. [174.21.149.226]) by smtp.gmail.com with ESMTPSA id z66sm14784091pfz.30.2020.04.07.17.50.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Apr 2020 17:50:40 -0700 (PDT) Subject: Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons To: Segher Boessenkool , Richard Henderson Cc: "Richard Earnshaw (lists)" , gcc-patches@gcc.gnu.org, marcus.shawcroft@arm.com, Wilco.Dijkstra@arm.com, richard.sandiford@arm.com References: <20200402185353.11047-1-richard.henderson@linaro.org> <868411a5-48fa-b025-0451-d23e72fbe37a@arm.com> <333e33ae-4836-1003-042e-80027ab38abd@arm.com> <20200407202745.GY26902@gate.crashing.org> <20200407235845.GF26902@gate.crashing.org> From: Richard Henderson Message-ID: Date: Tue, 7 Apr 2020 17:50:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200407235845.GF26902@gate.crashing.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 08 Apr 2020 00:50:43 -0000 On 4/7/20 4:58 PM, Segher Boessenkool wrote: >> I wonder if it would be helpful to have >> >> (uoverflow_plus x y carry) >> (soverflow_plus x y carry) >> >> etc. > > Those have three operands, which is nasty to express. How so? It's a perfectly natural operation. > On rs6000 we have the carry bit as a separate register (it really is > only one bit, XER[CA], but in GCC we model it as a separate register). > We handle it as a fixed register (there is only one, and saving and > restoring it is relatively expensive, so this worked out the best). As for most platforms, more or less. > Still, in the patterns (for insns like "adde") that take both a carry > input and have it as output, the expression for the carry output but > already the one for the GPR output become so unwieldy that nothing > can properly work with it. So, in the end, I have all such insns that > take a carry input just clobber their carry output. This works great! Sure, right up until the point when you want to actually *use* that carry output. Which is exactly what we're talking about here. > Expressing the carry setting for insns that do not take a carry in is > much easier. You get somewhat different patterns for various > immediate inputs, but that is all. It's not horrible, but it's certainly verbose. If we add a shorthand for that common operation, so much the better. I would not expect optimizers to take a collection of inputs and introduce this rtx code, but only operate with it when the backend emits it. >> This does have the advantage of avoiding the extensions, so that constants can >> be retained in the original mode. > > But it won't ever survive simplification; or, it will be in the way of > simplification. How so? It's clear that (set (reg:CC_C flags) (uoverflow_plus:CC_C (reg:SI x) (const_int 0) (const_int 0))) cannot overflow. Thus this expression as a whole would, in combination with the user of the CC_MODE, e.g. (set (reg:SI y) (ne:SI (reg:CC_C flags) (const_int 0)) fold to (set (reg:SI y) (ne:SI (const_int 0) (const_int 0)) to (set (reg:SI y) (const_int 0)) just like any other (compare) + (condition) pair. I don't see why this new rtx code is any more difficult than ones that we have already. >> Though of course if we go this way, there will be incentive to add >> overflow codes for all __builtin_*_overflow_p. > > Yeah, eww. And where will it stop? What muladd insns should we have > special RTL codes for, for the high part? Well, we don't have overflow builtins for muladd yet. Only plus, minus, and mul. Only x86 and s390x have insns to support overflow from mul without also computing the highpart. But add/sub-with-carry are *very* common operations. As are add/sub-with-carry with signed overflow into flags. It would be nice to make that as simple as possible across all targets. r~