From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36598 invoked by alias); 15 Aug 2019 18:30:26 -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 36583 invoked by uid 89); 15 Aug 2019 18:30:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=vmakarovredhatcom, vmakarov@redhat.com 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, 15 Aug 2019 18:30:24 +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 6D16787630; Thu, 15 Aug 2019 18:30:22 +0000 (UTC) Received: from tobol.usersys.redhat.com (unused-10-15-17-174.yyz.redhat.com [10.15.17.174]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3BAB85D6A9; Thu, 15 Aug 2019 18:30:20 +0000 (UTC) Subject: Re: Indirect memory addresses vs. lra To: Richard Biener , gcc@gcc.gnu.org, John Darrington Cc: Jeff Law , Segher Boessenkool , Paul Koning 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> From: Vladimir Makarov Message-ID: <61d0afa8-2253-1a52-9081-42983f48ada7@redhat.com> Date: Thu, 15 Aug 2019 18:30: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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00114.txt.bz2 On 8/15/19 12:38 PM, Richard Biener wrote: > 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: >>> >>> 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. >>> >>> I've attached such a dump (generated from >> gcc/testsuite/gcc.c-torture/compile/pr53410-2.c). >>> >>> 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). >>> >>> >>> J' >>> >> Thank you for providing the sources.  It helped me to understand what >> is >> going on.  So the test crashes on >> >> /home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c: >> In function ‘f1’: >> /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 require the frame pointer), spill the frame pointer, reload the first computed address from the stack, execute the insn and then reload the frame pointer. > > Maybe the frame pointer can also be implemented 'virually' in an index register 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 > Addressing... (is there an indirect lea?) > Yes, it could be a solution.  It just needs some target maintainer creativity.  There are a lot of things (tricks) can be done in machine-dependent code which would not require RA changes.