From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62263 invoked by alias); 15 Aug 2019 21:22:59 -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 62254 invoked by uid 89); 15 Aug 2019 21:22:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*f:sk:61d0afa, H*i:sk:61d0afa, HContent-Transfer-Encoding:8bit, H*Ad: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; Thu, 15 Aug 2019 21:22:58 +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 x7FLMlrd012400; Thu, 15 Aug 2019 16:22:47 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x7FLMkWJ012397; Thu, 15 Aug 2019 16:22:46 -0500 Date: Thu, 15 Aug 2019 21:22:00 -0000 From: Segher Boessenkool To: Vladimir Makarov Cc: Richard Biener , gcc@gcc.gnu.org, John Darrington , Jeff Law , Paul Koning Subject: Re: Indirect memory addresses vs. lra Message-ID: <20190815212245.GR31406@gate.crashing.org> References: <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> <61d0afa8-2253-1a52-9081-42983f48ada7@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <61d0afa8-2253-1a52-9081-42983f48ada7@redhat.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00117.txt.bz2 On Thu, Aug 15, 2019 at 02:30:19PM -0400, Vladimir Makarov wrote: > >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. You can even go as far as not having the hard frame pointer be a machine register at all. In RTL it will still be a reg, but that doesn't mean the machine code you emit should be like that; you can use a special fixed memory location for it, for example. Segher