From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 12956385BF81 for ; Wed, 8 Apr 2020 09:06:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 12956385BF81 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=richard.sandiford@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B475231B; Wed, 8 Apr 2020 02:06:42 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C59F43F73D; Wed, 8 Apr 2020 02:06:41 -0700 (PDT) From: Richard Sandiford To: Segher Boessenkool Mail-Followup-To: Segher Boessenkool , "Richard Earnshaw \(lists\)" , Richard Henderson , gcc-patches@gcc.gnu.org, marcus.shawcroft@arm.com, Wilco.Dijkstra@arm.com, richard.sandiford@arm.com Cc: "Richard Earnshaw \(lists\)" , Richard Henderson , gcc-patches@gcc.gnu.org, marcus.shawcroft@arm.com, Wilco.Dijkstra@arm.com Subject: Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons 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> Date: Wed, 08 Apr 2020 10:06:40 +0100 In-Reply-To: <20200407202745.GY26902@gate.crashing.org> (Segher Boessenkool's message of "Tue, 7 Apr 2020 15:27:45 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-13.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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 09:06:44 -0000 Segher Boessenkool writes: > On Mon, Apr 06, 2020 at 12:19:42PM +0100, Richard Sandiford wrote: >> The reason I'm not keen on using special modes for this case is that >> they'd describe one way in which the result can be used rather than >> describing what the instruction actually does. The instruction really >> does set all four flags to useful values. The "problem" is that they're >> not the values associated with a compare between two values, so representing >> them that way will always lose information. > > CC modes describe how the flags are set, not how the flags are used. > You cannot easily describe the V bit setting with a compare (it needs > a mode bigger than the register), is that what you mean? I meant more that, if you want to represent the result of SBCS using a compare, you have to decide ahead of time which result you're interested in, and pick the CC mode and compare representation accordingly. E.g. SBCS res, x, y sets the Z flag if res is zero. This is potentially useful, and could be represented as a compare:CC_Z (say) between values based on x, y and the C flag. SBCS res, x, y also sets the C flag if the first multiword value (x and less significant words) is GEU the second. This too is potentially useful and could be represented as a compare:CC_C (say) between values based on x, y and the C flag. But these two compares can't be the *same* compares, because SBCS can create a Z-set, C-clear result that is impossible for single compares. This is a case that the existing aarch64 pattern I mentioned gets wrong: (define_insn "*usub3_carryinC" [(set (reg:CC CC_REGNUM) (compare:CC (zero_extend: (match_operand:GPI 1 "register_operand" "r")) (plus: (zero_extend: (match_operand:GPI 2 "register_operand" "r")) (match_operand: 3 "aarch64_borrow_operation" "")))) (set (match_operand:GPI 0 "register_operand" "=r") (minus:GPI (minus:GPI (match_dup 1) (match_dup 2)) (match_operand:GPI 4 "aarch64_borrow_operation" "")))] "" "sbcs\\t%0, %1, %2" [(set_attr "type" "adc_reg")] ) (op3 == inverse of the carry flag). When op0 == 0, op2 == -1 and op3 == 1, the compare folds to: (compare:CC 0 (1 << 32)) for SI. This compare ought to give an NE result, but the SBCS instead sets the Z flag, giving an EQ result. That's what I meant by the CC mode describing how the result is used. You have to pick from a choice of several mutually-exclusive compare representations depending on which result you want. Sure, each representation has to describe how the flags are set in an accurate way (like the compare:CC_Z and compare:CC_C above are individually accurate). But the choice of CC mode does reflect how the result is used, and can't be made independently of how the result is used. For SUBS you can pick the mode of the compare and the compared values independently of how the result is used. This seems cleaner and leads to be better CSE opportunities, etc. I think it'd be good to be able to do the same for SBCS, whether that's through an unspec or (better) a new rtx_code. Thanks, Richard