From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83115 invoked by alias); 9 Aug 2019 17:34:42 -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 83105 invoked by uid 89); 9 Aug 2019 17:34:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=am, UD:a.m, a.m, solving 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 17:34:40 +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 6020799BAC; Fri, 9 Aug 2019 17:34:39 +0000 (UTC) Received: from [10.10.124.24] (ovpn-124-24.rdu2.redhat.com [10.10.124.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 011CA1001DC0; Fri, 9 Aug 2019 17:34:37 +0000 (UTC) Subject: Re: Indirect memory addresses vs. lra To: John Darrington , Jeff Law Cc: Segher Boessenkool , Paul Koning , 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: Vladimir Makarov Message-ID: <70b9bcc9-e12a-78b4-b8cc-a67b7ca3d38d@redhat.com> Date: Fri, 09 Aug 2019 17:34:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190809081439.baoyu3ii5i2qfbzt@jocasta.intra> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00071.txt.bz2 On 2019-08-09 4:14 a.m., 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. Basically, LRA behaves here as older reload.  If an RTL insn needs hard regs and there are no free regs, LRA/reload put pseudos assigned to hard regs and living through the insn into memory.  So it is very hard to run into problem "unable to find a register to spill", if the insn needs less regs provided by architecture. That is why people are surprised.  Still it can happens as one RTL insn can be implemented by a few machine insns.  Most frequent case here are GCC asm insns requiring a lot of input/output/and clobbered regs/operands. If you provide LRA dump for such test (it is better to use -fira-verbose=15 to output full RA info into stderr), I probably could say more. The less regs the architecture has, the easier to run into such error message if something described wrong in the back-end.  I see your architecture is 16-bit micro-controller with only 8 regs, some of them is specialized.  So your architecture is really register constrained. > 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? > > 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. LRA/reload is the most machine-dependent machine-independent pass in GCC.  It is connected to machine-dependent code by numerous ways. Big part of making a new backend  is to make LRA/reload and machine-dependent code communication in the right way. Sometimes it is hard to decide who is responsible for RA related bugs: RA or back-end.  Sometimes an innocent change in RA solving one problem for a particular target might results in numerous new bugs for other targets.  Therefore it is very difficult to say will your small change to permit indirect memory addressing work in general case.