From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54050 invoked by alias); 24 Nov 2015 13:06:33 -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 54033 invoked by uid 89); 24 Nov 2015 13:06:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,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 13:06:31 +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 C44A849; Tue, 24 Nov 2015 05:06:12 -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 B651F3F51B; Tue, 24 Nov 2015 05:06:28 -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> Cc: James Greenhalgh , Bin Cheng , gcc-patches List From: Jiong Wang Message-ID: <565460D3.9070708@foss.arm.com> Date: Tue, 24 Nov 2015 13:13: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: <56543963.3070704@foss.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02899.txt.bz2 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; 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]