From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129246 invoked by alias); 24 Nov 2015 14:51:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 129234 invoked by uid 89); 24 Nov 2015 14:51:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Nov 2015 14:51:30 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 11B7546A; Tue, 24 Nov 2015 06:51:11 -0800 (PST) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3DEA53F51B; Tue, 24 Nov 2015 06:51:27 -0800 (PST) Subject: Re: [PATCH AArch64]Handle REG+REG+CONST and REG+NON_REG+CONST in legitimize address To: Jiong Wang , "Bin.Cheng" References: <000001d12119$49548570$dbfd9050$@arm.com> <20151117100800.GA6727@arm.com> <564F5ABF.2020302@foss.arm.com> <5654343A.2080609@foss.arm.com> <56543963.3070704@foss.arm.com> <565460D3.9070708@foss.arm.com> <565464C4.7060704@foss.arm.com> <565475F1.1000105@foss.arm.com> Cc: James Greenhalgh , Bin Cheng , gcc-patches List From: Richard Earnshaw Message-ID: <5654796D.9070401@foss.arm.com> Date: Tue, 24 Nov 2015 14:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565475F1.1000105@foss.arm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02915.txt.bz2 On 24/11/15 14:36, Jiong Wang wrote: > > > On 24/11/15 13:23, Richard Earnshaw wrote: >> On 24/11/15 13:06, Jiong Wang wrote: >>> >>> On 24/11/15 10:18, Richard Earnshaw wrote: >>>> I presume you are aware of the canonicalization rules for add? That >>>> is, >>>> for a shift-and-add operation, the shift operand must appear first. >>>> Ie. >>>> >>>> (plus (shift (op, op)), op) >>>> >>>> not >>>> >>>> (plus (op, (shift (op, op)) >>>> >>>> R. >>> Looks to me it's not optimal to generate invalid mem addr, for example >>> (mem (plus reg, (mult reg, imm))) or even the simple (mem (plus (plus r, >>> r), imm), >>> in the first place. Those complex rtx inside is hidden by the permissive >>> memory_operand predication, and only exposed during reload by stricter >>> constraints, then reload need to extra work. If we expose those >>> complex rtx >>> earlier then some earlier rtl pass may find more optimization >>> opportunities, for >>> example combine. >>> >>> The following simple modification fix the ICE and generates best >>> sequences to me: >>> >>> - return gen_rtx_fmt_ee (PLUS, addr_mode, base, op1); >>> + addr = gen_rtx_fmt_ee (PLUS, addr_mode, op1, base); >>> + emit_insn (gen_rtx_SET (base, addr)); >>> + return base; >>> >> That wouldn't be right either if op1 could be a const_int. > > Indeed, though it would be strange to me if op1 would be const_int here, > given > those early if check, if it is, then the incoming address rtx would be > something > like the following without two const_int folded. > > + > / \ > / \ > + const_int > / \ > / \ > Reg const_int > > or we could sync the rtx checked in the early > aarch64_legitimate_address_hook_p, > it will return false if op1 be const_int. > > - rtx addr = gen_rtx_fmt_ee (PLUS, addr_mode, base, op1); > + rtx addr = gen_rtx_fmt_ee (PLUS, addr_mode, op1, base); > > The safest thing is to insert a call to swap_commutative_operands_p and then switch the order over if that returns true. R. >> >> R. >> >>> 67 add x1, x29, 48 >>> 68 add x1, x1, x0, sxtw 3 >>> 69 stlr x19, [x1] >>> >>> instead of >>> >>> 67 add x1, x29, 64 >>> 68 add x0, x1, x0, sxtw 3 >>> 69 sub x0, x0, #16 >>> 70 stlr x19, [x0] >>> >>> or >>> >>> 67 sxtw x0, w0 >>> 68 add x1, x29, 48 >>> 69 add x1, x1, x0, sxtw 3 >>> 70 stlr x19, [x1] >>> >>> >>> >>> >>> >