From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26084 invoked by alias); 8 Aug 2019 17:25:49 -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 26063 invoked by uid 89); 8 Aug 2019 17:25:46 -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=peephole X-HELO: resqmta-po-07v.sys.comcast.net Received: from resqmta-po-07v.sys.comcast.net (HELO resqmta-po-07v.sys.comcast.net) (96.114.154.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Aug 2019 17:25:45 +0000 Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-07v.sys.comcast.net with ESMTP id vlVFhTtCTOOQpvmAZhnlwe; Thu, 08 Aug 2019 17:25:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1565285143; bh=zTSLz3ark0xp4rZ9TTQF2kSRD5TUIXCRrVDue23A62Q=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=f1f/+kLJs/cx+qK5Thdkf+VD0KHXvXuju05OI970eQFOyokCG73rXehTVDwm6R4H2 sXalSVaK3cf2fNn3dzCSJkbIJGLekOApFCvK1nYnX3SjGjl1QKHqE/Hkq7oihubWDb kZwysOK15QSJbipF3MNuM4G7ptNC6r8j2ukDUztbqFXDaPH2gXYxw2za//TTPbAFb6 GWFcU2SeDGEmlNI2EKg83Brhlsz0FDounPBn6xjkH/wPxuHf2E4PnXofcd2u6sg3pv PrvHcte99lFUliWPuDIJ2SEumTj/PhHzKlCQWN9kWz9HFGk7fFsKmvu/TVVWQ7eL/A khnQhBEb6mN9Q== Received: from pkoning.akdesign.com ([73.60.223.101]) by resomta-po-15v.sys.comcast.net with ESMTPSA id vmAJhRnJDx9EhvmALh82lH; Thu, 08 Aug 2019 17:25:38 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduvddrudduhedguddugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpefrrghulhcumfhonhhinhhguceophgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtqeenucfkphepjeefrdeitddrvddvfedruddtudenucfrrghrrghmpehhvghlohepphhkohhnihhnghdrrghkuggvshhighhnrdgtohhmpdhinhgvthepjeefrdeitddrvddvfedruddtuddpmhgrihhlfhhrohhmpehprghulhhkohhnihhnghestghomhgtrghsthdrnhgvthdprhgtphhtthhopehsvghghhgvrheskhgvrhhnvghlrdgtrhgrshhhihhnghdrohhrghdprhgtphhtthhopehvmhgrkhgrrhhovhesrhgvughhrghtrdgtohhmpdhrtghpthhtohepjhhohhhnsegurghrrhhinhhgthhonhdrfigrthhtlhgvrdhiugdrrghupdhrtghpthhtohepghgttgesghgttgdrghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedt 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: <20190808172102.GH31406@gate.crashing.org> Date: Thu, 08 Aug 2019 17:25:00 -0000 Cc: Vladimir Makarov , John Darrington , gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190804191822.x4hwnfcyplnto3xc@jocasta.intra> <2B3A4EAB-D69E-4714-8FC4-C25E36B07BFF@comcast.net> <20190808172102.GH31406@gate.crashing.org> To: Segher Boessenkool X-SW-Source: 2019-08/txt/msg00046.txt.bz2 > On Aug 8, 2019, at 1:21 PM, Segher Boessenkool wrote: >=20 > On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote: >>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov wro= te: >>> The old reload (reload[1].c) supports such addressing. As modern mains= tream architectures have no this kind of addressing, it was not implemented= in LRA. >>=20 >> Is LRA only intended for "modern mainstream architectures"? >=20 > I sure hope not! But it has only been *used* and *tested* much on such, > so far. Things are designed to work well for modern archs. >=20 >> If yes, why is the old reload being deprecated? You can't have it both = ways. Unless you want to obsolete all "not modern mainstream architectures= " in GCC, it doesn't make sense to get rid of core functionality used by th= ose architectures. >>=20 >> Indirect addressing is a key feature in size-optimized code. >=20 > That doesn't mean that LRA has to support it, btw, not necessarily; it > may well be possible to do a good job of this in the later passes? > Maybe postreload, maybe some peepholes, etc.? Possibly. But as Vladimir points out, indirect addressing affects register= allocation (reducing register pressure). In older architectures that impl= ement indirect addressing, that is one of the key ways in which the feature= reduces code size. While I can see how peephole optimization can convert = a address load plus a register indirect into a memory indirect instruction,= does that help the register become available for other uses or is post-LRA= too late for that? My impression is that it is too late, since at this po= int we're dealing with hard registers and making one free via peephole help= s no one else. paul