From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-199918-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6413 invoked by alias); 15 Aug 2019 17:41:59 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 6405 invoked by uid 89); 15 Aug 2019 17:41:59 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-8.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:D1EAC18, H*f:sk:D1EAC18, H*Ad:U*john
X-HELO: jocasta.intra
Received: from de.cellform.com (HELO jocasta.intra) (88.217.224.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Aug 2019 17:41:57 +0000
Received: from jocasta.intra (localhost [127.0.0.1])	by jocasta.intra (8.15.2/8.15.2/Debian-8) with ESMTPS id x7FHfnXD028400	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);	Thu, 15 Aug 2019 19:41:49 +0200
Received: (from john@localhost)	by jocasta.intra (8.15.2/8.15.2/Submit) id x7FHfnjV028399;	Thu, 15 Aug 2019 19:41:49 +0200
Date: Thu, 15 Aug 2019 17:41:00 -0000
From: John Darrington <john@darrington.wattle.id.au>
To: Richard Biener <richard.guenther@gmail.com>
Cc: gcc@gcc.gnu.org, Vladimir Makarov <vmakarov@redhat.com>,        John Darrington <john@darrington.wattle.id.au>,        Jeff Law <law@redhat.com>,        Segher Boessenkool <segher@kernel.crashing.org>,        Paul Koning <paulkoning@comcast.net>
Subject: Re: Indirect memory addresses vs. lra
Message-ID: <20190815174148.4pdum5srubvs7bqb@jocasta.intra>
References: <2B3A4EAB-D69E-4714-8FC4-C25E36B07BFF@comcast.net> <20190808172102.GH31406@gate.crashing.org> <2EEBCFAE-FF25-4664-AA5F-B3299CEA3CB1@comcast.net> <20190808191914.GK31406@gate.crashing.org> <dca38a3f-91db-9483-dd0e-0075ef501624@redhat.com> <20190809081439.baoyu3ii5i2qfbzt@jocasta.intra> <70b9bcc9-e12a-78b4-b8cc-a67b7ca3d38d@redhat.com> <20190810060553.m6e42sovw7s4xqoa@jocasta.intra> <be60bf0c-c5f4-dff1-267c-d426d0c6c44e@redhat.com> <D1EAC183-4384-4404-90FF-CC30FD365131@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D1EAC183-4384-4404-90FF-CC30FD365131@gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-IsSubscribed: yes
X-SW-Source: 2019-08/txt/msg00112.txt.bz2

On Thu, Aug 15, 2019 at 06:38:30PM +0200, Richard Biener 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.  lea x, [4,x] is a valid instruction.

J'

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.