From patchwork Mon Jan 31 13:27:02 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 81101 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]) by ozlabs.org (Postfix) with SMTP id E1CD6B70EC for ; Tue, 1 Feb 2011 00:27:15 +1100 (EST) Received: (qmail 6752 invoked by alias); 31 Jan 2011 13:27:13 -0000 Received: (qmail 6744 invoked by uid 22791); 31 Jan 2011 13:27:13 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-bw0-f47.google.com (HELO mail-bw0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 31 Jan 2011 13:27:08 +0000 Received: by bwz10 with SMTP id 10so5710011bwz.20 for ; Mon, 31 Jan 2011 05:27:05 -0800 (PST) Received: by 10.204.57.13 with SMTP id a13mr5303959bkh.75.1296480425335; Mon, 31 Jan 2011 05:27:05 -0800 (PST) Received: from richards-thinkpad (gbibp9ph1--blueice3n2.emea.ibm.com [195.212.29.84]) by mx.google.com with ESMTPS id rc9sm8816692bkb.14.2011.01.31.05.27.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 05:27:04 -0800 (PST) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: [ARM] PR 47553: vld1q_lane_u8 & co. don't accept lanes >= 8 Date: Mon, 31 Jan 2011 13:27:02 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 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 The v{ld,st}1q_lane_{u,s,p}8 intrinsic functions are supposed to take a range between 0 and 15. The function is then converted to a vld1 or vst1 of one half of the quad value. The problem is that the lane predicate doesn't account for this, and only accepts the 0..7 range that are supported by the individual vld1 and vst1. The current code only does the "real" size-dependent range check at output time. That isn't ideal, but there's a separate bug (40884) about it. Tested on arm-linux-gnueabi (-marm and -mthumb). I don't think this is a regression, so: OK to install once 4.7 is open? Richard gcc/ * config/arm/predicates.md (neon_lane_number): Accept 0..15. gcc/testsuite/ * gcc.target/arm/neon-vld-1.c: New test. Index: gcc/config/arm/predicates.md =================================================================== --- gcc/config/arm/predicates.md 2011-01-31 13:09:19.000000000 +0000 +++ gcc/config/arm/predicates.md 2011-01-31 13:12:41.000000000 +0000 @@ -610,7 +610,7 @@ (define_predicate "neon_inv_logic_op2" ;; TODO: We could check lane numbers more precisely based on the mode. (define_predicate "neon_lane_number" (and (match_code "const_int") - (match_test "INTVAL (op) >= 0 && INTVAL (op) <= 7"))) + (match_test "INTVAL (op) >= 0 && INTVAL (op) <= 15"))) ;; Predicates for named expanders that overlap multiple ISAs. (define_predicate "cmpdi_operand" Index: gcc/testsuite/gcc.target/arm/neon-vld-1.c =================================================================== --- /dev/null 2011-01-26 10:43:14.268819722 +0000 +++ gcc/testsuite/gcc.target/arm/neon-vld-1.c 2011-01-31 13:16:10.000000000 +0000 @@ -0,0 +1,13 @@ +/* { dg-do compile } */ +/* { dg-require-effective-target arm_neon_ok } */ +/* { dg-options "-O1" } */ +/* { dg-add-options arm_neon } */ + +#include + +uint8x16_t +foo (uint8_t *a, uint8x16_t b) +{ + vst1q_lane_u8 (a, b, 14); + return vld1q_lane_u8 (a + 0x100, b, 15); +}