From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98833 invoked by alias); 9 Aug 2019 16:07:02 -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 98825 invoked by uid 89); 9 Aug 2019 16:07:02 -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; Fri, 09 Aug 2019 16:07:00 +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 2E8D751F1C; Fri, 9 Aug 2019 16:06:59 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-27.rdu2.redhat.com [10.10.112.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4DC255D6A5; Fri, 9 Aug 2019 16:06:57 +0000 (UTC) Subject: Re: Indirect memory addresses vs. lra To: John Darrington Cc: Segher Boessenkool , Paul Koning , Vladimir Makarov , 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> <20190809081439.baoyu3ii5i2qfbzt@jocasta.intra> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <197ca5dd-b137-b922-0a28-b31fdd501315@redhat.com> Date: Fri, 09 Aug 2019 16:07: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: <20190809081439.baoyu3ii5i2qfbzt@jocasta.intra> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00070.txt.bz2 On 8/9/19 2:14 AM, 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. You're going to have to debug what LRA is doing and why. There's really no short-cuts here. We can't really do it for you. Even if you weren't using LRA you'd be doing the same process, just on even more difficult to understand codebase. > > 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. So perhaps there is another, yet to be > discovered, restriction which prevents my backend from ever working? It's possible. But that's not really any different than reload. There's certainly various aspects of architectures that reload can't handle as well -- even on architectures that were mainstream processors when reload was under active development and maintenance. THere's even a good chance reload won't handle double-indirect addressing modes well -- they were far from mainstream and as a result the code which does purport to handle double-indirect addressing modes hasn't been used/tested all that much over the last 25+ years. > > 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. My recommendation is to continue with the LRA path. jeff