From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p05-ob.smtp.rzone.de (mo4-p05-ob.smtp.rzone.de [81.169.146.183]) by sourceware.org (Postfix) with ESMTPS id 67270386102B for ; Fri, 18 Dec 2020 17:13:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 67270386102B X-RZG-AUTH: ":LXoWVUeid/7A29J/hMvvT3koxZnKT7Qq0xotTetVnKkbgtK4qmy+J0bTJvSd" X-RZG-CLASS-ID: mo05 Received: from [192.168.2.101] by smtp.strato.de (RZmta 47.9.3 DYNA|AUTH) with ESMTPSA id 602e28wBIHDD2aI (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Fri, 18 Dec 2020 18:13:13 +0100 (CET) Message-ID: <5FDCE332.50607@gcc.gnu.org> Date: Fri, 18 Dec 2020 18:13:22 +0100 From: Georg-Johann Lay User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Segher Boessenkool CC: Paul Koning , Senthil Kumar Selvaraj , Ilias Lazaridis , Denis Chertykov , GCC Patches Subject: Re: [PATCH] avr: cc0 to mode_cc conversion References: <5FD662CF.3080701@gjlay.de> <87a6ucu8g0.fsf@gcc.gnu.org> <20201217112107.GO2672@gate.crashing.org> <681759BA-E38E-4E29-AF8F-2175342818C1@comcast.net> <20201218091351.GP2672@gate.crashing.org> In-Reply-To: <20201218091351.GP2672@gate.crashing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NEUTRAL, TXREP 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 17:13:18 -0000 Segher Boessenkool schrieb: > 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.) As far as I understand, targets that clobber condition code in mov or add3 must use approach #2. #1 is not a problem if the target still uses IRA (like avr does), but LRA cannot handle clobbers of the condition code (in terms or explicit clobbers). Hence, targets that clobber cc in mov or add3 must use #2 because IRA/reload will also be kicked out before very soon. Or am I missing something? Johann