From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3265 invoked by alias); 8 Aug 2019 16:44:24 -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 3173 invoked by uid 89); 8 Aug 2019 16:44:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=Vladimir, Makarov, vladimir, makarov X-HELO: resqmta-po-02v.sys.comcast.net Received: from resqmta-po-02v.sys.comcast.net (HELO resqmta-po-02v.sys.comcast.net) (96.114.154.161) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Aug 2019 16:44:20 +0000 Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-02v.sys.comcast.net with ESMTP id vid1h7IrHkHCivlWUhAjBt; Thu, 08 Aug 2019 16:44:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1565282658; bh=Q05x02dbOXxhtPXRJ3RzPZHqLAIQcTWANGqRiyjJAxw=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=Dm+E6wa1eJxmM/zusSdwR8ViDG773ZIiBRcf942NLiN2p+BqpN1id8U+cf6UtmH4v YifDo+Cd5wxfGwgEOyJQFNyfI4R2DUJrgs0NATn2Bxm1KUOgZZGEjWiO7YRVLTmkOe 9+Y/l59k3cj8HzNxcqWr0BVuO8zRC7ECL44mX1oL8SwIzqPEWQNYraUrMQZW+KQeyO AedgVwGdOfhNVsKNctX5J5gnmzURZofVyDQSVA8IzjHI27qyQdp6KUCFX6J22ZxSw8 Vu5md90/N5rOF/S95WpSu2ScpN2Su9MHy92k2Zrw1qJoguryU6S2ScPc4bacvQvyQ8 /LwXHwrs40slg== Received: from pkoning.akdesign.com ([73.60.223.101]) by resomta-po-09v.sys.comcast.net with ESMTPSA id vlW6hsT2xSZxGvlW7hoDZ7; Thu, 08 Aug 2019 16:44:18 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduvddrudduhedguddthecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpefrrghulhcumfhonhhinhhguceophgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtqeenucfkphepjeefrdeitddrvddvfedruddtudenucfrrghrrghmpehhvghlohepphhkohhnihhnghdrrghkuggvshhighhnrdgtohhmpdhinhgvthepjeefrdeitddrvddvfedruddtuddpmhgrihhlfhhrohhmpehprghulhhkohhnihhnghestghomhgtrghsthdrnhgvthdprhgtphhtthhopehvmhgrkhgrrhhovhesrhgvughhrghtrdgtohhmpdhrtghpthhtohepjhhohhhnsegurghrrhhinhhgthhonhdrfigrthhtlhgvrdhiugdrrghupdhrtghpthhtohepghgttgesghgttgdrghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-Xfinity-VMeta: sc=-100;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Indirect memory addresses vs. lra From: Paul Koning In-Reply-To: Date: Thu, 08 Aug 2019 16:44:00 -0000 Cc: John Darrington , gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <2B3A4EAB-D69E-4714-8FC4-C25E36B07BFF@comcast.net> References: <20190804191822.x4hwnfcyplnto3xc@jocasta.intra> To: Vladimir Makarov X-SW-Source: 2019-08/txt/msg00042.txt.bz2 > On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wrote: >=20 >=20 > On 2019-08-04 3:18 p.m., John Darrington wrote: >> I'm trying to write a back-end for an architecture (s12z - the ISA you c= an >> download from [1]). This arch accepts indirect memory addresses. That= is to >> say, those of the form (mem (mem (...))) and although my TARGET_LEGITIM= ATE_ADDRESS >> function returns true for such addresses, LRA insists on reloading them = out of >> existence. >> ... > The old reload (reload[1].c) supports such addressing. As modern mainstr= eam architectures have no this kind of addressing, it was not implemented i= n LRA. Is LRA only intended for "modern mainstream architectures"? If yes, why is the old reload being deprecated? You can't have it both way= s. Unless you want to obsolete all "not modern mainstream architectures" i= n GCC, it doesn't make sense to get rid of core functionality used by those= architectures. Indirect addressing is a key feature in size-optimized code. paul