From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126677 invoked by alias); 15 Aug 2019 16:38:38 -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 126668 invoked by uid 89); 15 Aug 2019 16:38:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:be60bf0, H*f:sk:be60bf0 X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Aug 2019 16:38:35 +0000 Received: by mail-wr1-f65.google.com with SMTP id s18so2005008wrn.1 for ; Thu, 15 Aug 2019 09:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=L9uMA4eAluHc/gI4bENsNPgDF0mejiChv6yLuhZl9K4=; b=dc8TNxONSIBltn+loyF6X3GcbjrYEhvYWHd+E/NVQ9BdHWwX4kTyE/Oqg38SiKBNpQ ZdvGs9Zol5GprAvzI7MatZeNnHLsfABo8IEMpfrN4Leq6T6DhRoa337GiWsHSP5XUZk4 hGx8d4UxpHlnJm0JH6p6IMPnI7KCGwYvzYbidOCAmotdVPCGELvEJhXCbtC2aUL3tZV4 VNUl2GxTu0w9X8w6SIO2HDs2xvbDKc/uISd4URktDcdRYU57m+ijwvw0jj0fSuCgL1I5 E8J95aM3/QJdrcyEGZWHEdokirz7KNSQJAfhzBhtI10Utmsz83jqY/KNaB1OnNcIk9yO ul2w== Return-Path: Received: from [192.168.178.32] (x4d02aa37.dyn.telefonica.de. [77.2.170.55]) by smtp.gmail.com with ESMTPSA id u129sm2471411wmb.12.2019.08.15.09.38.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Aug 2019 09:38:32 -0700 (PDT) Date: Thu, 15 Aug 2019 16:38:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: 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> <70b9bcc9-e12a-78b4-b8cc-a67b7ca3d38d@redhat.com> <20190810060553.m6e42sovw7s4xqoa@jocasta.intra> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Indirect memory addresses vs. lra To: gcc@gcc.gnu.org,Vladimir Makarov ,John Darrington CC: Jeff Law ,Segher Boessenkool ,Paul Koning From: Richard Biener Message-ID: X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00110.txt.bz2 On August 15, 2019 6:29:13 PM GMT+02:00, Vladimir Makarov wrote: >On 8/10/19 2:05 AM, John Darrington wrote: >> On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote: >>=20=20=20=20=20=20=20 >> If you provide LRA dump for such test (it is better to use >> -fira-verbose=3D15 to output full RA info into stderr), I >probably could >> say more. >> >> I've attached such a dump (generated from >gcc/testsuite/gcc.c-torture/compile/pr53410-2.c). >>=20=20=20=20=20=20=20 >> The less regs the architecture has, thoke 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. >> >> That's not quite correct. It is a 24-bit micro-controller (the >address >> space is 24 bits wide). There are 2 address registers (plus stack >> pointer and program counter) and there are 8 general purpose data >> registers (of differing sizes). >>=20=20=20=20=20=20=20 >> >> J' >> >Thank you for providing the sources.=C2=A0 It helped me to understand what >is=20 >going on.=C2=A0 So the test crashes on > >/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c: >In function =E2=80=98f1=E2=80=99: >/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1: >error: unable to find a register to spill >/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1: >error: this is the insn: >(insn 14 49 15 2 (set (mem:SI (plus:PSI (reg/f:PSI 40 [34]) > (const_int 32 [0x20])) [2 S4 A64]) >(mem:SI (reg:PSI 41) [2 *p_5(D)+0 S4 A8])) >"/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c":9:9 >95 {*movsi} > (expr_list:REG_DEAD (reg:PSI 41) > (expr_list:REG_DEAD (reg/f:PSI 40 [34]) > (nil)))) > >Your target has only 2 non-fixed addr registers (r8, r9). One (r9) is >defined as a hard reg pointer pointer. Honestly, I never saw a target >with such register constraints. > >-O0 assumes -fno-omit-frame-pointer. So in -O0 mode we have only *one* >free addr reg for insn which requires *2* of them. That is why the GCC >port crashes on this test. If you add -fomit-frame-pointer, the test >succeeds. > >But even if use -fomit-frame-pointer, it is not guaranteed that hard >reg pointer will be substituted by stack pointer. There are many cases >where it is not possible (e.g. in case of alloca usage). > >So what can be done, imho. The simplest solution would be preventing >insns with more one memory operand. The more difficult solution would >be permitting two memory one with address pseudo and another one with >stack pointer. Couldn't we spill the frame pointer? Basically we should be able to compute= the first address into a reg, spill that, do the second (both could requir= e the frame pointer), spill the frame pointer, reload the first computed ad= dress from the stack, execute the insn and then reload the frame pointer. Maybe the frame pointer can also be implemented 'virually' in an index regi= ster that you keep updated so that sp + reg Is the FP. Or frame accesses can use a Stack slot as FP and the indirect memory=20 Addressing... (is there an indirect lea?)=20 >I think only after solving this problem, you could think about >implementing indirect memory addressing. > >=20=20