From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78025 invoked by alias); 8 Aug 2019 19:57:47 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 78017 invoked by uid 89); 8 Aug 2019 19:57:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,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; Thu, 08 Aug 2019 19:57:45 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 98C57D9831; Thu, 8 Aug 2019 19:57:44 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-43.rdu2.redhat.com [10.10.112.43]) by smtp.corp.redhat.com (Postfix) with ESMTP id D3C5746E61; Thu, 8 Aug 2019 19:57:42 +0000 (UTC) Subject: Re: Indirect memory addresses vs. lra To: Segher Boessenkool , Paul Koning Cc: Vladimir Makarov , John Darrington , gcc@gcc.gnu.org References: <20190804191822.x4hwnfcyplnto3xc@jocasta.intra> <2B3A4EAB-D69E-4714-8FC4-C25E36B07BFF@comcast.net> <20190808172102.GH31406@gate.crashing.org> <2EEBCFAE-FF25-4664-AA5F-B3299CEA3CB1@comcast.net> <20190808191914.GK31406@gate.crashing.org> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Thu, 08 Aug 2019 19:57: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: <20190808191914.GK31406@gate.crashing.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00058.txt.bz2 On 8/8/19 1:19 PM, Segher Boessenkool wrote: > On Thu, Aug 08, 2019 at 01:30:41PM -0400, Paul Koning wrote: >> >> >>> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool wrote: >>> >>> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote: >>>>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: >>>>> The old reload (reload[1].c) supports such addressing. As modern mainstream architectures have no this kind of addressing, it was not implemented in LRA. >>>> >>>> Is LRA only intended for "modern mainstream architectures"? >>> >>> I sure hope not! But it has only been *used* and *tested* much on such, >>> so far. >> >> That's not entirely accurate. At the prodding of people pushing for >> the removal of CC0 and reload, I've added LRA support to pdp11 in the >> V9 cycle. > > I said "much" :-) > > Pretty much all design input so far has been from "modern mainstream > architectures", as far as I can make out. Now one of those has the > most "interesting" (for RA) features that many less mainstream archs > have (a not-so-very-flat register file), so it should still work pretty > well hopefully. Yea, it's certainly designed with the more mainstream architectures in mind. THe double-indirect case that's being talked about here is well out of the mainstream and not a feature of anything LRA has targetted to date. So I'm not surprised it's not working. My suggestion would be to ignore the double-indirect aspect of the architecture right now, get the port working, then come back and try to make double-indirect addressing modes work. > >> And it works pretty well, in the sense of passing the >> compile tests. But I haven't yet examined the code quality vs. the >> old one in any detail. > > That would be quite interesting to see, also for the other ports that > still need conversion: how much (if any) degradation should you expect > from a straight-up conversion of a port to LRA, without any retuning? I did the v850 last year where it was a wash or perhaps a slight improvement for codesize, which is a reasonable approximation for performance on that target. I was working a bit on converting the H8 away from cc0 with an eye towards LRA as well. Given how registers overlap on the H8, the most straightforward port should end up with properties much like 32bit x86. I suspect the independent addressing of the high/low register parts might be better handled by LRA, but I wasn't going to do anything beyond the "just make it work". jeff