From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52522 invoked by alias); 1 Oct 2019 19:29:47 -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 52513 invoked by uid 89); 1 Oct 2019 19:29:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,GIT_PATCH_2,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 01 Oct 2019 19:29:45 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 49A43307D96F; Tue, 1 Oct 2019 19:29:44 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-17.rdu2.redhat.com [10.10.112.17]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5029E1001B05; Tue, 1 Oct 2019 19:29:43 +0000 (UTC) Subject: Re: AW: make static method find_reloads_address_1(...) extern accessible To: stefan@franke.ms, gcc-help@gcc.gnu.org References: <006001d57789$02636170$072a2450$@franke.ms> <2af0f71b-ea6d-982e-f779-84f097fa59ad@redhat.com> <00a401d577b4$034d16a0$09e743e0$@franke.ms> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Tue, 01 Oct 2019 19:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <00a401d577b4$034d16a0$09e743e0$@franke.ms> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00009.txt.bz2 On 9/30/19 11:25 AM, stefan@franke.ms wrote: > > >> -----Ursprüngliche 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 >> >> 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. => 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 biggest >> worry is any data structures used by find_reloads_address_1 and it's children >> and whether or not that data is valid. > > It seems to work, passes the gcc.c-torture/execute tests... Well, that's good, but not really sufficient to determine if the patch is correct. > >> The bigger concern I have is that we're on a path to drop reload and instead >> use LRA. So there's a good chance that the work you do in this space doesn'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. >> >> 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 this >> 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/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases I'm aware. Depending on a variety of things, my son might take a stab at it next summer if nobody else has. He helped on the v850 conversion and has done some work on an h8 conversion. The idea was to start with easier ports, working towards the m68k. But again, it's not a firm commitment. > > And I am confident that an adequate implementation for LRA can be done. I'm much more concerned about the cc0 transition than LRA. Conversion to LRA is almost certainly a much smaller change. > > Should I use the gcc development master branch (version 10 atm) or something stable for LRA? GCC master. Note that LRA does not support cc0 targets. SO the cc0 transition has to happen first. jeff