From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) by sourceware.org (Postfix) with ESMTPS id 76677385141F for ; Tue, 5 Jan 2021 19:06:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 76677385141F Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-04v.sys.comcast.net with ESMTP id woB7kQ1BQbVMMwrelkLusx; Tue, 05 Jan 2021 19:06:11 +0000 Received: from [IPv6:2601:191:200:1838:58d4:fab7:2d85:75ab] ([IPv6:2601:191:200:1838:58d4:fab7:2d85:75ab]) by resomta-po-16v.sys.comcast.net with ESMTPSA id wrejkfmKNrkvTwrekkodoi; Tue, 05 Jan 2021 19:06:11 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit From: Paul Koning Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Subject: Re: [PATCH] avr: cc0 to mode_cc conversion Date: Tue, 5 Jan 2021 14:06:09 -0500 References: <5FD662CF.3080701@gjlay.de> <87a6ucu8g0.fsf@gcc.gnu.org> <878s97zdz0.fsf@gcc.gnu.org> To: Senthil Kumar Selvaraj , GCC Patches In-Reply-To: <878s97zdz0.fsf@gcc.gnu.org> Message-Id: <6CB60A01-4230-47C2-A6ED-A6C8A1977710@comcast.net> X-Mailer: Apple Mail (2.3445.104.17) X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, JMQ_SPF_NEUTRAL, SPF_HELO_NONE, SPF_PASS, 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: Tue, 05 Jan 2021 19:06:14 -0000 > On Jan 5, 2021, at 8:54 AM, Senthil Kumar Selvaraj via Gcc-patches = wrote: >=20 >=20 > Senthil Kumar Selvaraj writes: >=20 >> Georg-Johann Lay writes: >>=20 >> ... >>>=20 >>> 2) We just saw 100reds of insns being dublicated, basically the = whole >>> machine description except for the few insns that leave cc alone. >>> Isn't is possible to use define subst for the bulk of the insns and >>> get a neat code that's better to grasp and to maintain? >>> After all it's just appending a clobber of reg_cc, and in the = current >>> proposal almost 50% of the backend is just redundent repetitions of >>> previous insns. >=20 > I could not find a way to get define_subst to do define_insn_and_split = - > other targets using the same approach (pdp11, h8300) have the > duplication as well. I ran into the same issue, I tried as well for the obvious reason. I'm = pretty sure someone told me (a) that doesn't work, and (b) the reason is = xyzzy. But I no long remember what the reason is, or even if I was told = one. The impression I have is that define_subst isn't a macro facility, even = though it looks a bit like one, and that may be why it can't do what you = want to do here. paul