From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122621 invoked by alias); 30 Sep 2019 17:25:22 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 122612 invoked by uid 89); 30 Sep 2019 17:25:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,GIT_PATCH_2,SPF_FAIL autolearn=ham version=3.3.1 spammy=ursprngliche, H*UA:Outlook, H*x:Outlook, H*UA:Microsoft X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Sep 2019 17:25:20 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iEzQD-0002m9-Lb for gcc-help@gcc.gnu.org; Mon, 30 Sep 2019 13:25:18 -0400 Received: from serveronline.org ([78.46.86.77]:48943 helo=franke.ms) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iEzQD-0002jS-Ff for gcc-help@gcc.gnu.org; Mon, 30 Sep 2019 13:25:17 -0400 Received: from Thinky (pD9E55BDC.dip0.t-ipconnect.de [217.229.91.220]) by serveronline.org (BEJY V1.6.12-SNAPSHOT (c) 2000-2019 by BebboSoft, Stefan "Bebbo" Franke, all rights reserved) with SMTP id 16d83345fe62408225fe4795176 from stefan@franke.ms for gcc-help@gcc.gnu.org; Mon, 30 Sep 2019 18:25:10 +0100 From: To: "'Jeff Law'" , References: <006001d57789$02636170$072a2450$@franke.ms> <2af0f71b-ea6d-982e-f779-84f097fa59ad@redhat.com> In-Reply-To: <2af0f71b-ea6d-982e-f779-84f097fa59ad@redhat.com> Subject: AW: make static method find_reloads_address_1(...) extern accessible Date: Mon, 30 Sep 2019 17:25:00 -0000 Message-ID: <00a401d577b4$034d16a0$09e743e0$@franke.ms> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 78.46.86.77 X-SW-Source: 2019-09/txt/msg00121.txt.bz2 > -----Urspr=C3=BCngliche Nachricht----- > Von: Jeff Law > Gesendet: Montag, 30. September 2019 18:23 > An: stefan@franke.ms; gcc-help@gcc.gnu.org > Betreff: Re: make static method find_reloads_address_1(...) extern > accessible >=20 > On 9/30/19 6:17 AM, stefan@franke.ms wrote: > > I've implemented LEGITIMIZE_RELOAD_ADDRESS and that implementation > is > > calling find_reloads_address_1. > > > > My implementation adds double indirect addressing to the m68k target > > and since the use of an outer index register or offset depends on the > > use of an inner index register or offset, since only one index > > register and one offset is allowed per address. =3D> The recursive > > reload implementation does not work. So the > LEGITIMIZE_RELOAD_ADDRESS > > takes care of the whole address at once. > > > > How are the chances that a static method of reload is converted into > > an extern accessible method, if a patch would requires it? > If all you need is to make the routine visible, that may be OK. THe bigg= est > worry is any data structures used by find_reloads_address_1 and it's chil= dren > and whether or not that data is valid. It seems to work, passes the gcc.c-torture/execute tests...=20 > The bigger concern I have is that we're on a path to drop reload and inst= ead > use LRA. So there's a good chance that the work you do in this space doe= sn't > have a significant lifetime -- doing it in LRA would be better, at least = in theory > -- and at least one other port would like to support double indirect > addressing in LRA. >=20 > The natural question is whether or not m68k can use LRA instead of reload. > That's predicated on converting the m68k from cc0 to MODE_CC for > representing the condition codes. Nobody is currently signed up to do th= is > work and if nobody steps up, the m68k port will end up deprecated. There's a bounty on bountysource for this: https://www.bountysource.com/iss= ues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-futur= e-releases And I am confident that an adequate implementation for LRA can be done. Should I use the gcc development master branch (version 10 atm) or somethin= g stable for LRA? Stefan