From patchwork Fri Jan 6 11:54:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kyrill Tkachov X-Patchwork-Id: 90152 Delivered-To: patch@linaro.org Received: by 10.182.224.138 with SMTP id rc10csp297473obc; Fri, 6 Jan 2017 03:55:17 -0800 (PST) X-Received: by 10.99.211.21 with SMTP id b21mr142413097pgg.120.1483703717734; Fri, 06 Jan 2017 03:55:17 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id t6si79364310pfa.280.2017.01.06.03.55.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jan 2017 03:55:17 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-return-445527-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org; spf=pass (google.com: domain of gcc-patches-return-445527-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-445527-patch=linaro.org@gcc.gnu.org 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:content-type; q=dns; s=default; b=PAz73Kbdi9RnnTSydhQEJ77uJcySMxR/IDLCQKm++0e ZTaZQtWbCrnLxKbVpkypqG45dcDujkXAhIY/xJrH7GBOUnRjbhp2wBHbUKnfiTjG puxd1b2WFJ3+m9KBVgiH8QEqZ6pprbtxP7mxokUN6KpeESszE1Pc4QDNC5SDUu9U = 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:content-type; s=default; bh=tqAyaaJNpdqTokwCrxggF9mKh5I=; b=WQ7oKHBiYI9sIn2HX la6207/9tiXXGvQh1um0McedFLVZRQ5IUNm+X83zza5KgI8ii/okWiY1pKocJLoV umavJ/3ob5fSAZsnFYVzsS9C6sMAjN+WsehleC7RuInTqCMO7FblJ+PJgttrroCZ QltpKQlY1Mu8WtirSC7X5f/XTc= Received: (qmail 36254 invoked by alias); 6 Jan 2017 11:55:06 -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 36234 invoked by uid 89); 6 Jan 2017 11:55:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=UD:f03, H*MI:arm 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; Fri, 06 Jan 2017 11:54:55 +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 B5BE5152D; Fri, 6 Jan 2017 03:54:53 -0800 (PST) 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 2436C3F220; Fri, 6 Jan 2017 03:54:53 -0800 (PST) Message-ID: <586F858B.5050209@foss.arm.com> Date: Fri, 06 Jan 2017 11:54:51 +0000 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: GCC Patches CC: Ramana Radhakrishnan , Richard Earnshaw Subject: [PATCH][ARM] PR target/71270 fix neon_valid_immediate for big-endian Hi all, In this wrong-code issue the RTL tries to load a const_vector: (const_vector:V8QI [ (const_int 1 [0x1]) (const_int 0 [0]) (const_int 1 [0x1]) (const_int 0 [0]) (const_int 1 [0x1]) (const_int 0 [0]) (const_int 1 [0x1]) (const_int 0 [0]) ]) into a NEON register. The logic for that is in neon_valid_immediate which does a number of tricks to decide what value and of what size to do a VMOV on to load the correct vector immediate into the register. It goes wrong on big-endian. On both big and little-endian this outputs: vmov.i16 d18, #0x1 This is wrong on big-endian. The vector layout has to be such as if loaded from memory. I've tried various approaches of fixing neon_valid_immediate to generate the correct immediate but have been unsuccessful, resulting in regressions in various parts of the testsuite or making a big mess of the function. Given that armeb is not a target of major concern I believe the safest route at this stage is to only allow vector constants that will obviously work on big-endian, that is the ones that are just a single element duplicated in all lanes. This patch fixes the execution failures: FAIL: gfortran.dg/intrinsic_pack_1.f90 FAIL: gfortran.dg/c_f_pointer_logical.f03 FAIL: gcc.dg/torture/pr60183.c FAIL: gcc.dg/vect/pr51581-4.c on armeb-none-eabi. Ok for trunk? Thanks, Kyrill 2017-01-06 Kyrylo Tkachov PR target/71270 * config/arm/arm.c (neon_valid_immediate): Reject vector constants in big-endian mode when they are not a single duplicated value. diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index 45e0a3cd11fa650f456f7382ffbbcd1c932b95eb..2beee8ebe94eeadd6fb1d5b119e3b474e1ab902a 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -11542,6 +11542,12 @@ neon_valid_immediate (rtx op, machine_mode mode, int inverse, return 18; } + /* The tricks done in the code below apply for little-endian vector layout. + For big-endian vectors only allow vectors of the form { a, a, a..., a }. + FIXME: Implement logic for big-endian vectors. */ + if (BYTES_BIG_ENDIAN && vector && !const_vec_duplicate_p (op)) + return -1; + /* Splat vector constant out into a byte vector. */ for (i = 0; i < n_elts; i++) {