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 59E0B385DC34 for ; Tue, 7 Apr 2020 19:43:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 59E0B385DC34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@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 037JhStU013184; Tue, 7 Apr 2020 14:43:28 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 037JhSuD013183; Tue, 7 Apr 2020 14:43:28 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 7 Apr 2020 14:43:27 -0500 From: Segher Boessenkool To: "Richard Earnshaw (lists)" Cc: Richard Henderson , gcc-patches@gcc.gnu.org, marcus.shawcroft@arm.com, Wilco.Dijkstra@arm.com, richard.sandiford@arm.com Subject: Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons Message-ID: <20200407194327.GX26902@gate.crashing.org> References: <20200402185353.11047-1-richard.henderson@linaro.org> <868411a5-48fa-b025-0451-d23e72fbe37a@arm.com> <333e33ae-4836-1003-042e-80027ab38abd@arm.com> <01ec0411-b9b0-7233-271e-98e5dc36c6e1@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ec0411-b9b0-7233-271e-98e5dc36c6e1@arm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-40.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no 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: Tue, 07 Apr 2020 19:43:34 -0000 Hi! On Tue, Apr 07, 2020 at 10:52:10AM +0100, Richard Earnshaw (lists) wrote: > On 06/04/2020 12:19, Richard Sandiford wrote: > > "Richard Earnshaw (lists)" writes: > >> Yes. It surprised me, when doing the aarch32 version, just how often > >> the mid-end parts of the compiler were able to reason about parts of the > >> parallel insn and optimize things accordingly (eg propagating the truth > >> of the comparison). If you use an unspec that can never happen. > > > > That could be changed though. E.g. we could add something like a > > simplify_unspec target hook if this becomes a problem (either here > > or for other unspecs). A fancy implementation could even use > > match.pd-style rules in the .md file. > > I really don't like that. It sounds like the top of a long slippery > slope. What about all the other cases where the RTL is comprehended by > the mid-end? Same here. And the interesting transforms are not done in simplify-rtx anyway, but in combine: simplify-rtx should only ever make a *simplified* representation, while combine makes a (single!) choice that works out the best in practice. You do need a few separate patterns (for reg, 0, pos, -1, other neg, for example), but then everything automatically works. The canonical way to write these insns is different for different constants, that is all. Segher