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 7BB143858D1E for ; Tue, 1 Nov 2022 20:36:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7BB143858D1E 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 2A1KYWPg023574; Tue, 1 Nov 2022 15:34:32 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2A1KYW4C023573; Tue, 1 Nov 2022 15:34:32 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 1 Nov 2022 15:34:31 -0500 From: Segher Boessenkool To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] x86: Replace ne:CCC/ne:CCO with UNSPEC_CC_NE in neg patterns Message-ID: <20221101203431.GM25951@gate.crashing.org> References: <20221026185857.234023-1-hjl.tools@gmail.com> <4752529.GXAFRqVoOG@fomalhaut> <20221028214303.GH25951@gate.crashing.org> <2132915.irdbgypaU6@fomalhaut> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2132915.irdbgypaU6@fomalhaut> 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: On Fri, Oct 28, 2022 at 11:55:35PM +0200, Eric Botcazou wrote: > > You mean in CCV? That works yes, but only because (or if) the setter > > and getter of the CC reg both use CCV (so never use any other flag at > > the same time; CCV has an empty intersection with all other CC modes). > > We're talking about CCC here AFAIK, i.e. the carry, not CCV. Yes. But it is all the same: neither signed overflow nor unsigned overflow (of an addition, say) can be described as the result of an RTL comparison. The point is that all of this is put completely outside of all other MODE_CC handling, and only works because of that. And a small modification to the backend, completely elsewhere, can make that house of cards collapse. It is much more robust to use a different relation, not EQ, to decribe this. Something with an unspec is fine. But what the sparc backend does does work. Segher