From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31832 invoked by alias); 19 Aug 2015 12:47:43 -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 31823 invoked by uid 89); 19 Aug 2015 12:47:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Aug 2015 12:47:41 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-31-nueE06EPSOSBURdyPKG76Q-1; Wed, 19 Aug 2015 13:47:37 +0100 Received: from E100706VM ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2015 13:47:36 +0100 From: "Kyrill Tkachov" To: "'Renlin Li'" , Cc: "Ramana Radhakrishnan" , "Richard Earnshaw" References: <55D46D44.3060005@arm.com> In-Reply-To: <55D46D44.3060005@arm.com> Subject: RE: [PATCH][ARM]Tighten the conditions for arm_movw, arm_movt Date: Wed, 19 Aug 2015 12:50:00 -0000 Message-ID: <000001d0da7d$2bc48150$834d83f0$@arm.com> MIME-Version: 1.0 X-MC-Unique: nueE06EPSOSBURdyPKG76Q-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg01072.txt.bz2 Hi Renlin, Please send patches to gcc-patches for review. Redirecting there now... On 19/08/15 12:49, Renlin Li wrote: > Hi all, > > This simple patch will tighten the conditions when matching movw and > arm_movt rtx pattern. > Those two patterns will generate the following assembly: > > movw w1, #:lower16: dummy + addend > movt w1, #:upper16: dummy + addend > > The addend here is optional. However, it should be an 16-bit signed > value with in the range -32768 <=3D A <=3D 32768. > > By impose this restriction explicitly, it will prevent LRA/reload code > from generation invalid high/lo_sum code for arm target. > In process_address_1(), if the address is not legitimate, it will try to > generate high/lo_sum pair to put the address into register. It will > check if the target support those newly generated reload instructions. > By define those two patterns, arm will reject them if conditions is not > meet. > > Otherwise, it might generate movw/movt instructions with addend larger > than 32768, this will cause a GAS error. GAS will produce '''offset out > of range'' error message when the addend for MOVW/MOVT REL relocation is > too large. > > > arm-none-eabi regression tests Okay, Okay to commit to the trunk and > backport to 5.0? > > Regards, > Renlin > > gcc/ChangeLog: > > 2015-08-19 Renlin Li > > * config/arm/arm-protos.h (arm_valid_symbolic_address_p): Declare. > * config/arm/arm.c (arm_valid_symbolic_address_p): Define. > * config/arm/arm.md (arm_movt): Use arm_valid_symbolic_address_p. > * config/arm/constraints.md ("j"): Add check for high code. +/* Returns true if the pattern is a valid symbolic address, which is eithe= r a + symbol_ref or a symbol_ref + offset. */ +bool +arm_valid_symbolic_address_p (rtx addr) New line between comment and function. +{ + rtx xop0, xop1 =3D NULL_RTX; + rtx tmp =3D addr; + + if (GET_CODE (tmp) =3D=3D SYMBOL_REF || GET_CODE (tmp) =3D=3D LABEL_REF) + return true; + + /* (const (plus: symbol_ref const_int)) */ + if (GET_CODE (addr) =3D=3D CONST) + tmp =3D XEXP (addr, 0); + + xop0 =3D XEXP (tmp, 0); + xop1 =3D XEXP (tmp, 1); Is it guaranteed that at this point XEXP (tmp, 0) and XEXP (tmp, 1) are val= id? I think before you extract xop0 and xop1 you want to check that tmp is inde= ed a PLUS and return false if it's not. Only then you should extract XEXP (tmp, 0) an= d XEXP (tmp, 1). + if (GET_CODE (tmp) =3D=3D PLUS && GET_CODE (xop0) =3D=3D SYMBOL_REF + && CONST_INT_P (xop1)) + { + HOST_WIDE_INT offset =3D INTVAL (xop1); + if (offset < -0x8000 || offset > 0x7fff) + return false; + else + return true; I think you can just do "return IN_RANGE (offset, -0x8000, 0x7ffff);" Thanks, Kyrill