From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58035 invoked by alias); 24 Nov 2015 14:36:39 -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 58021 invoked by uid 89); 24 Nov 2015 14:36:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_05,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:36:37 +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 E42CD46A; Tue, 24 Nov 2015 06:36:18 -0800 (PST) Received: from [10.2.206.22] (e104437-lin.cambridge.arm.com [10.2.206.22]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F0A4E3F51B; Tue, 24 Nov 2015 06:36:34 -0800 (PST) Subject: Re: [PATCH AArch64]Handle REG+REG+CONST and REG+NON_REG+CONST in legitimize address To: Richard Earnshaw , "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> Cc: James Greenhalgh , Bin Cheng , gcc-patches List From: Jiong Wang Message-ID: <565475F1.1000105@foss.arm.com> Date: Tue, 24 Nov 2015 14:39: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: <565464C4.7060704@foss.arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02912.txt.bz2 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); > > 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] >> >> >> >> >>