From patchwork Tue Sep 27 13:55:48 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kyrill Tkachov X-Patchwork-Id: 675621 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3sk2Rw1l7gz9sBr for ; Tue, 27 Sep 2016 23:56:11 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=C7rZXASQ; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=QRjI2pglHQ0in7zFX5cew7+Dcj1pWirdOREHsXsz3D70whkvqFlsB KFbKnb4eSFlAYRX3jbIArYOjLLzxG17IuONbNKYHxtDsxhElPzgWQ6lAet56bLGq wjtlf1N/bpaJKSqHUeHQ9d46bHN0FC/THI1Jw4LBy6CeeCAfUjPEjQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s=default; bh=JR0kwLQBLjHaWEsjCcPnenKlFqk=; b=C7rZXASQXHQRuxctax9P9Z1/AEv8 BSVdacBWs8Ba/tjjR0CquzM5BXYjvV7yMGQb+8a86pGRincWztYw6V9ln0KeZ/es WMSzhzSxklCzRKbSV1SrVySmSv749sqG5on7dyNIn9S+/7vuG6z6Y7gGCCOCiKyw YIjul6ddb6z2U7s= Received: (qmail 58068 invoked by alias); 27 Sep 2016 13:56:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 58038 invoked by uid 89); 27 Sep 2016 13:56:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=interest 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, 27 Sep 2016 13:55:52 +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 20FAD28; Tue, 27 Sep 2016 06:55:50 -0700 (PDT) Received: from [10.2.207.77] (e100706-lin.cambridge.arm.com [10.2.207.77]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7DE2E3F21A; Tue, 27 Sep 2016 06:55:49 -0700 (PDT) Message-ID: <57EA7A64.5070709@foss.arm.com> Date: Tue, 27 Sep 2016 14:55:48 +0100 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Matthew Wahab , gcc-patches CC: Christophe Lyon Subject: Re: [ARM] Fix invalid instructions generated for data movement. References: <57EA7250.2000607@foss.arm.com> In-Reply-To: <57EA7250.2000607@foss.arm.com> Hi Matthew, On 27/09/16 14:21, Matthew Wahab wrote: > Recently added support for ARMv8.2-A > (https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01240.html) included a > number of changes to improve data movement, particularly for HI and HF > mode values. These included the use of the Thumb-2 instruction MOVW and > of the new VMOV.F16 instruction. There are problems with both: the use > of MOVW isn't properly guarded so that it can be generated for targets > that don't support it and the VMOV.F16 instruction is wrongly marked as > being predicable. > > This patch adds guards to the use of the MOVW so that it is only > generated when the target supports Thumb-2 and fixes the predication on > the VMOV.F16 instruction. > > Tested for arm-none-linux-gnueabihf with native bootstrap and make check > on ARMv8-A and for arm-none-eabi with cross compiled check-gcc on an > ARMv8.2-A emulator. > > There is one failure on arm-none-linux-gnueabihf, > gcc.dg/guality/pr36728-1.c which is due to MOVW not being generated, > even for ARMv7-A. The generated code is otherwise correct. I think I > understand why MOVW isn't being emitted but it'll take time to test > properly. > > Since this patch is to fix a broken build is it OK to commit it and to fix > the poor code-gen in a follow-up patch? > Matthew > > gcc/ > 2016-09-27 Matthew Wahab > > * config/arm/arm.md (*arm_movsi_insn): Add "arch" attribute. > * config/arm/vfp.md (*arm_movhi_vfp): Likewise. > (*thumb2_movhi_vfp): Likewise. > (*arm_movhi_fp16): Remove predication operand from VMOV.F16 > template. Expand predicable attribute to mark VMOV.F16 as not > predicable. Add "arch" attribute. > (*thumb2_movhi_fp16): Likewise. > (*arm_movsi_vfp): Break a long line. Add "arch" attribute. > (*thumb2_movsi_vfp): Add "arch" attribute. The "t2" attribute means that we're currently compiling for Thumb2. What you want is to check that the architecture we're compiling for supports Thumb2, so in this case you want the v6t2 value. In the interest of fixing the build I'll approve this patch as is since it's still correct (just not as general as it could be), but it'd be good to have a follow-up patch to fix this. Thanks for fixing this, Kyrill diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md index 411754f..999292b 100644 --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -6065,6 +6065,7 @@ [(set_attr "type" "mov_reg,mov_imm,mvn_imm,mov_imm,load1,store1") (set_attr "predicable" "yes") (set_attr "pool_range" "*,*,*,*,4096,*") + (set_attr "arch" "*,*,*,t2,*,*") (set_attr "neg_pool_range" "*,*,*,*,4084,*")] )