From patchwork Tue Sep 10 19:09:42 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 274000 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 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id ECEEB2C01D3 for ; Wed, 11 Sep 2013 05:10:17 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; q=dns; s=default; b=YXIA5oa3vrxnBU2n i7Uq3Ohaf+qs7zsUEFK9yu/T9oY91HGhBsl9UATnqYakoeDeoqKACokxKf2GFI9V jLmZh5pmQASSXtS08v1MYf4cbFD/u7C1mvqU4PZfPZZ/5HDjM/Vua2xwkintMsso ZeZFq1YlsPUZiJZffW+wpYQ7iTk= 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:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; s=default; bh=MDsN6jwreiDqgF+TE7sp7C 1mxnw=; b=LlLp9C0nR1SPo9Yw3HXmIfcay9RhhYiA5mQZRmW2Gobz0tkphXzvdD VytMsIy0iv6KK28SJZWodyuFytOb8qwBkFprcBHuO/JNUwkEfiZgbY0jhWDqS3dC VOv8nyMOs0rBZkNfA3XlNUp/AZhyEd42jq4BAonBuUZB9yF/agSuo= Received: (qmail 22592 invoked by alias); 10 Sep 2013 19:09:56 -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 22453 invoked by uid 89); 10 Sep 2013 19:09:55 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 10 Sep 2013 19:09:55 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED, BAYES_00, FREEMAIL_FROM autolearn=ham version=3.3.2 X-HELO: mail-wg0-f43.google.com Received: by mail-wg0-f43.google.com with SMTP id z12so7065356wgg.10 for ; Tue, 10 Sep 2013 12:09:51 -0700 (PDT) X-Received: by 10.181.12.16 with SMTP id em16mr14053638wid.36.1378840191043; Tue, 10 Sep 2013 12:09:51 -0700 (PDT) Received: from localhost ([95.148.201.183]) by mx.google.com with ESMTPSA id fv10sm5180855wic.0.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 10 Sep 2013 12:09:50 -0700 (PDT) From: Richard Sandiford To: James Greenhalgh Mail-Followup-To: James Greenhalgh , gcc-patches@gcc.gnu.org, richard.guenther@gmail.com, rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org, richard.guenther@gmail.com Subject: Re: [1/4] Using gen_int_mode instead of GEN_INT References: <1378833157-11511-1-git-send-email-james.greenhalgh@arm.com> Date: Tue, 10 Sep 2013 20:09:42 +0100 In-Reply-To: <1378833157-11511-1-git-send-email-james.greenhalgh@arm.com> (James Greenhalgh's message of "Tue, 10 Sep 2013 18:12:37 +0100") Message-ID: <87y574mr2h.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 James Greenhalgh writes: > This seems to have caused PR58373. The bug occurs where GEN_INT would > previously have then been used to build a constant of vector mode. > > These pop in a few places when building for AArch64, though I did > the debugging using gcc.target/aarch64/vect-fcm-eq-d.c > > Here we could get in to the situation where > simplify_unary_expression_1 would see (V2DI: NOT (NEG X)) > and try to generate (V2DI: PLUS (X - 1)). In turn, we would reach the > call in plus_constant to gen_int_mode (-1, v2di), followed by > trunc_int_for_mode (-1, v2di) and this assert would trigger: > > /* You want to truncate to a _what_? */ > gcc_assert (SCALAR_INT_MODE_P (mode)); > > In this fix I catch the case where gen_int_mode has been asked to > build a vector mode, and call trunc_int_for_mode on the inner mode > of that vector. A similar fix could sit in trunc_int_for_mode if > you would prefer. > > Bootstrapped on x86_64-unknown-linux-gnu with no issues and regression > tested for aarch64-none-elf with the expected benefits and no regressions. Sorry for the breakage. gen_int_mode and GEN_INT really are only for scalar integers though. (So is plus_constant.) Vector constants should be CONST_VECTORs rather than CONST_INTs. I think the gcc.target/aarch64/vect-fcm-eq-d.c failure is from a latent bug in the way (neg (not ...)) and (not (neg ...)) are handled. Could you give the attached patch a go? I looked through the other calls to plus_constant in simplify-rtx.c, but they seem OK. Thanks, Richard gcc/ * simplify-rtx.c (simplify_unary_operation_1): Use simplify_gen_binary for (not (neg ...)) and (neg (not ...)) casees. Index: gcc/simplify-rtx.c =================================================================== --- gcc/simplify-rtx.c 2013-09-10 20:02:08.756091875 +0100 +++ gcc/simplify-rtx.c 2013-09-10 20:02:09.002093907 +0100 @@ -825,7 +825,8 @@ simplify_unary_operation_1 (enum rtx_cod /* Similarly, (not (neg X)) is (plus X -1). */ if (GET_CODE (op) == NEG) - return plus_constant (mode, XEXP (op, 0), -1); + return simplify_gen_binary (PLUS, mode, XEXP (op, 0), + CONSTM1_RTX (mode)); /* (not (xor X C)) for C constant is (xor X D) with D = ~C. */ if (GET_CODE (op) == XOR @@ -932,7 +933,8 @@ simplify_unary_operation_1 (enum rtx_cod /* Similarly, (neg (not X)) is (plus X 1). */ if (GET_CODE (op) == NOT) - return plus_constant (mode, XEXP (op, 0), 1); + return simplify_gen_binary (PLUS, mode, XEXP (op, 0), + CONST1_RTX (mode)); /* (neg (minus X Y)) can become (minus Y X). This transformation isn't safe for modes with signed zeros, since if X and Y are