From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64437 invoked by alias); 9 Aug 2019 14:17:41 -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 64429 invoked by uid 89); 9 Aug 2019 14:17:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=Nah, nah, human, HTo:U*john 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 ESMTP; Fri, 09 Aug 2019 14:17:37 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x79EGjX9009037; Fri, 9 Aug 2019 09:16:45 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x79EGig4009035; Fri, 9 Aug 2019 09:16:44 -0500 Date: Fri, 09 Aug 2019 14:17:00 -0000 From: Segher Boessenkool To: John Darrington Cc: Jeff Law , Paul Koning , Vladimir Makarov , gcc@gcc.gnu.org Subject: Re: Indirect memory addresses vs. lra Message-ID: <20190809141644.GM31406@gate.crashing.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> <20190809081439.baoyu3ii5i2qfbzt@jocasta.intra> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190809081439.baoyu3ii5i2qfbzt@jocasta.intra> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00068.txt.bz2 Hi! On Fri, Aug 09, 2019 at 10:14:39AM +0200, John Darrington wrote: > On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: > > 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. > > This sounds like sensible advice. However I wonder if this issue is > related to the other major outstanding problem I have, viz: the large > number of test failures which report "Unable to find a register to > spill" - So far, nobody has been able to explain how to solve that > issue and even the people who appear to be more knowlegeable have > expressed suprise that it is even happening at all. No one is surprised. It is just the funny way that LRA says "whoops I am going in circles, there is no progress and there will never be, I'd better stop that". Everyone doing new ports / new conversions to LRA sees that error all the time. The error could be pretty much *anywhere* in your port. You have to look at what LRA did, and why, and why that is wrong, and fix that. > Even if it should turn out not to be related, the message I've been > receiving in this thread is lra should not be expected to work for > non "mainstream" backends. LRA is more likely to have problems in situations where it has not been tested before. You can replace LRA by anything else, and this isn't limited to GCC (or software, or human endeavours, or humanity even). > So perhaps there is another, yet to be > discovered, restriction which prevents my backend from ever working? >From ever? Nah, we can patch. Also, Occam's razor says there likely is an error in your backend you haven't found yet. > On the other hand, given my lack of experience with gcc, it could be > that lra is working perfectly, and I have simply done something > incorrectly. But the uncertainty voiced in this thread means that it > is hard to be sure that I'm not trying to do something which is > currently unsupported. Is your code in some branch in our git? Or in some other public git? Do you have a representative testcase? Segher