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 5C952385800C for ; Fri, 18 Dec 2020 09:15:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5C952385800C 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 0BI9Dp2r020476; Fri, 18 Dec 2020 03:13:52 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 0BI9DpE6020466; Fri, 18 Dec 2020 03:13:51 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 18 Dec 2020 03:13:51 -0600 From: Segher Boessenkool To: Paul Koning Cc: Senthil Kumar Selvaraj , GCC Patches , Denis Chertykov , Ilias Lazaridis Subject: Re: [PATCH] avr: cc0 to mode_cc conversion Message-ID: <20201218091351.GP2672@gate.crashing.org> References: <5FD662CF.3080701@gjlay.de> <87a6ucu8g0.fsf@gcc.gnu.org> <20201217112107.GO2672@gate.crashing.org> <681759BA-E38E-4E29-AF8F-2175342818C1@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <681759BA-E38E-4E29-AF8F-2175342818C1@comcast.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, 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: Fri, 18 Dec 2020 09:15:58 -0000 On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote: > > On Dec 17, 2020, at 6:21 AM, Segher Boessenkool wrote: > > On Thu, Dec 17, 2020 at 02:15:51PM +0530, Senthil Kumar Selvaraj via Gcc-patches wrote: > >> The work on my github branch was not complete - I'd blindly followed > >> whatever the CC0 Transition wiki mentioned (the first three steps of > >> case #2), and fixed any regression fallout (for ATmega128). > >> > >> I intend to try out a define_subst/early clobber of reg_cc based > >> approach (inspired by the cris port) and see if that can help avoid the > >> proliferation of define_insn_and_splits. Will update how that works out. > > > > Yeah, case #2 does not necessarily give the best result, but it usually > > is the least work to do, so certainly a good choice under time pressure. > > I was under the impression from what I read in the blog a year or two ago (when I did the pdp11 ccmode work) that "case 2" is the better answer for machines in which pretty much every operation touches the condition codes. In other words, I understood that case 1 would for such machines not be the right answer -- it wasn't just that "case 2 is easier". > > Did I misunderstand? Is there a reason for machines such as pdp11, in which basically every operation that handles data, even a move instruction, touches CC, to use approach 1? No, you didn't misunderstand. I said "not necessarily" for a reason :-) If there are move insns that do *not* clobber CC, it can be different, but if even move instructions do, a case #2 conversion is a good choice. (This is all my opinion, but I think it is not controversial.) Segher