From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98444 invoked by alias); 28 Sep 2015 21:20:40 -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 98364 invoked by uid 89); 28 Sep 2015 21:20:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 28 Sep 2015 21:20:33 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id t8SLKST9030086; Mon, 28 Sep 2015 16:20:28 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id t8SKSkOr025203; Mon, 28 Sep 2015 15:29:04 -0500 Date: Mon, 28 Sep 2015 22:48:00 -0000 From: Segher Boessenkool To: Vladimir Makarov Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Convert SPARC to LRA Message-ID: <20150928202838.GA1401@gate.crashing.org> References: <20150908.214115.1585933992134500164.davem@davemloft.net> <2D64499C-B66A-4873-BDB9-C6190FF539FE@comcast.net> <56089802.7010803@redhat.com> <560993B9.70105@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560993B9.70105@redhat.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg02155.txt.bz2 On Mon, Sep 28, 2015 at 03:23:37PM -0400, Vladimir Makarov wrote: > There are more ports using reload than LRA now. Even some major ports > (e.g. ppc64) did not switch to LRA. There still are some failures in the testsuite (ICEs even) so we're not there yet. > I usually say target maintainers, that if they don't switch LRA they > probably will have problems with maintenance and development in a long > perspective. New things are easier to implement in LRA. It is also true that new *ports* are easier to do with LRA than with reload :-) > >It *may* be time to decree that any new ports must use the LRA path > >rather than reload. I'm still on the fence with that. > > That is probably a good policy I see now. Porting LRA might be not an > easy task as a lot of target hooks (and even insn definitions, e.g. > hints *?!) were written taking reload algorithms into account. LRA uses > different ones and many hook implementations are misleading. Many > target ports are just in a maintenance mode and simply there are no > resources to do LRA port for this targets. So I believe reload will > stay for a long time. We can at least change the default to LRA, so new ports get it unless they like to hurt themselves. I don't think it makes sense to keep reload around *just* for the ports that are in "maintenance mode": by the time we are down to *just* those ports, it makes more sense to relabel them as "unmaintained". Segher