From patchwork Wed Jun 14 10:21:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kyrill Tkachov X-Patchwork-Id: 775721 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 3wnjNS2xnZz9s65 for ; Wed, 14 Jun 2017 20:21:44 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="TLUjP9lz"; 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=caxj3XSRaP3nPDNgcU5LYI9pg6Pw6qgBoxboa/jNlbIiiKG1wAt0E EX7LYml41bOcpsJeR34wKA3Epu7FjystpKAFhJe5KH5YQV3IpdrqVwxq4O1H8NUJ MmbaHjx22pwzgm0X/WpyvEang4i9jtNIvHgj2rJHcItW1sogxDCaIc= 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=Pz64R1AS7ywexJ3Di+9VqB73l9U=; b=TLUjP9lzg7yEf1SvKrxXtYlpGGuJ DS469vtur86l9obinUOOioSa+6Pxg5Zv37nszTkBXVRtt0Kp7NODWqttSsTtk9pI DfnPjb8mxs73aCqw4d0Shltq31NLuvb+6zi/JG8H1N2fXVcU5bPVrsAqTvQ76xyo +e9+XVFAqaQdbgk= Received: (qmail 61243 invoked by alias); 14 Jun 2017 10:21:31 -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 61202 invoked by uid 89); 14 Jun 2017 10:21:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=righthand, Hx-languages-length:3096, right-hand 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; Wed, 14 Jun 2017 10:21:29 +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 B92311596; Wed, 14 Jun 2017 03:21:32 -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 89D3D3F581; Wed, 14 Jun 2017 03:21:31 -0700 (PDT) Message-ID: <59410E2A.1020808@foss.arm.com> Date: Wed, 14 Jun 2017 11:21:30 +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: James Greenhalgh , gcc-patches@gcc.gnu.org CC: nd@arm.com, ramana.radhakrishnan@arm.com, kyrtka01@arm.com, richard.earnshaw@arm.com, nickc@redhat.com Subject: Re: [Patch ARM] Fix PR71778 References: <1497275869-1612-1-git-send-email-james.greenhalgh@arm.com> In-Reply-To: <1497275869-1612-1-git-send-email-james.greenhalgh@arm.com> Hi James, On 12/06/17 14:57, James Greenhalgh wrote: > Hi, > > PR71778 is an ICE when you pass a non-constant argument to an intrinsic > which requires a constant. > > This ICE was introduced after we rewrote some of the builtin handling for > Neon intrinsics, the issue is that after throwing an error in > arm_expand_builtin_args, we return const0_rtx to indicate the expand > has failed > > if (!(*insn_data[icode].operand[opno].predicate) > (op[argc], mode[argc])) > { > error ("%Kargument %d must be a constant immediate", > exp, argc + 1); > return const0_rtx; > } > > At this point we're safely in to invalid code, but the mid-end continues > trying to resolve the assignment, with const0_rtx on the right-hand > side. That gets in to trouble in movv2di, which sees the constant and > tries to expand through neon_make_constant, which doesn't expect to see > a const0_rtx in the assignment (it wants a vector), and we hit a > gcc_unreachable () and take the ICE. That movv2di expander is the one in vec-common.md that ends up calling neon_make_constant. I wonder why const0_rtx passed its predicate check (that would require a V2DImode vector of zeroes rather than a const0_rtx). Perhaps the midend code at this point doesn't check the operand predicate. In the builtin expansion code that you quoted I wonder wonder if we could fail more gracefully by returning CONST0_RTX (mode[argc]) to match the expected mode of the operand (we've already emitted an error, so we shouldn't care what RTL we emit as long as it doesn't cause an ICE). > There are a few moving parts in the back end, so it isn't clear to me that > the fix I've come up with is 100% in the right place. AArch64 doesn't > bother with a similar construct, expanding straight to a mov with whatever > you've given it, so I don't see a right place over there. > > The change is defensible, but I don't really know the ARM back end. > > Bootstrapped on arm-none-linux-gnueabihf. > > OK? > > Thanks, > James > > --- > gcc/ > > 2017-06-12 James Greenhalgh > > PR target/71778 > * config/arm/arm.c (neon_make_constant): Return const0_rtx for > const0_rtx input. > > gcc/testsuite/ > > 2017-06-12 James Greenhalgh > > PR target/71778 > * gcc.target/arm/pr71778.c: New. > I'm not a fan of this as the function has a precondition that its argument is a PARALLEL or a CONST_VECTOR and special-casing const0_rtx breaks that. I'd rather we tried fixing this closer to the error source. Can you try the suggestion above instead please? Thanks, Kyrill diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index e503891..b8d59c6 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -12124,6 +12124,11 @@ neon_make_constant (rtx vals) if (n_const == n_elts) const_vec = gen_rtx_CONST_VECTOR (mode, XVEC (vals, 0)); } + else if (vals == const0_rtx) + /* Something invalid, perhaps from expanding an intrinsic + which requires a constant argument, where a variable argument + was passed. */ + return const0_rtx; else gcc_unreachable ();