From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108616 invoked by alias); 22 Sep 2019 12:02:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 108603 invoked by uid 89); 22 Sep 2019 12:02:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Envelope-From:sk:richard, HX-Received:dcca, quality, HX-HELO:sk:mail-ed X-HELO: mail-ed1-f49.google.com Received: from mail-ed1-f49.google.com (HELO mail-ed1-f49.google.com) (209.85.208.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 22 Sep 2019 12:02:50 +0000 Received: by mail-ed1-f49.google.com with SMTP id l21so5416952edr.5 for ; Sun, 22 Sep 2019 05:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=S+uASNc/T7pKLce+aaORpUbrOsHr3JGdxL9Qm7dRmWg=; b=CKkmZgWfRNZXeq2DeJIR/h4hC5F7RW9IaNsQChJdY+5y3q90cUrlwnJx9PfM862hiG Zi/NAoEkSFHYQxHHQf6G+u7ebvsL2o1iOjS5nKtHvZitQlthTdtidoOhcB7MJRGHS17b 69QDfL7PU4xtx78vQPbxLZ6DUg+Lca/N6q8Sj3pZ5YkzMHVyY7AhGlM7r3nP30WQo6L3 4gTMEyUbBZnvwJRG/h3D2m2BUR9nH8VJPboojgIcw0/zw3pgNuD5LoPd9BxwkFa7fuW3 W62iENRp1l3iWqlGjmOKj3mwuB7oUbnFfFKJdugUQA2fp/5zagwFgNe6bfhtuXp6sceI yn8A== Return-Path: Received: from [192.168.178.32] (x5f720009.dyn.telefonica.de. [95.114.0.9]) by smtp.gmail.com with ESMTPSA id p19sm1668711edq.31.2019.09.22.05.02.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Sep 2019 05:02:47 -0700 (PDT) Date: Sun, 22 Sep 2019 12:02:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <20190921234834.GA9749@gate.crashing.org> References: <1ee03bc0-ad1a-46dd-87bb-8288e990ce20@redhat.com> <3D71D7C0-1155-4B1C-822F-3B3D49134DC7@gmail.com> <00982305-c6c7-27f9-7819-9bca5a8c249f@redhat.com> <81ED8054-FFE6-4832-BAE5-3C7C639B8ADB@comcast.net> <20190921234834.GA9749@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Deprecating cc0 (and consequently cc0 targets) To: Segher Boessenkool ,Jeff Law CC: Paul Koning ,gcc-patches@gcc.gnu.org,Denis Chertykov ,hp@axis.com,Andreas Schwab ,Matt Thomas From: Richard Biener Message-ID: X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg01309.txt.bz2 On September 22, 2019 1:48:34 AM GMT+02:00, Segher Boessenkool wrote: >On Sat, Sep 21, 2019 at 03:04:26PM -0600, Jeff Law wrote: >> On 9/21/19 2:48 PM, Paul Koning wrote: >> >> On Sep 20, 2019, at 1:45 PM, Jeff Law wrote: >> >> On 9/20/19 11:22 AM, Richard Biener wrote: >> >> Now if someone did a variant #2 without the optimization bits (ie, > >> >> adding appropriate _set_flags pattern variants), I think that >> >> should be considered explicitly OK even though the code quality >> >> would potentially suffer. Essentially it's a choice between >> >> dropping the port or keeping the port, but with slightly less >> >> optimization. THe latter seems like a better choice to me. >> >=20 >> > True. Then again, the added work of creating the pattern pairs is >> > modest. With define_subst, much of the work can be automated. >> The patterns and support to handle optimization can be added after >the >> basic conversion is done. In fact, that's precisely how I'd approach >it. > >Yeah, but a type #2 conversion is more than that; it makes it harder to >do a type #1 conversion later than if you started with doing just that. >Of course it is better than totally dropping a target. Some >coordination >would be useful. > >OTOH, a type #2 conversion seems easy enough that maybe we can just >pull >that off for *all* targets for GCC 10, and actually remove CC0 already? That was exactly my thinking...=20 >> > For pdp11, I found this to be the case; the hard part was to learn >> > what is needed, and for that the Wiki ends up a big help. Also, >> > pdp11 is harder than most because it has two CC registers (one for >> > float ops, one for the rest). I don't know all the others, but for >> > example VAX only has one, and I'm pretty sure the same applies to >> > m68k. >> m68k is like pdp11 in this regard. Two condition code registers, one >in >> the main processor and another for the 68881 FP unit. > >I think the main difficulty with m68k is that it is a pretty big >target. > > >Segher