From patchwork Wed Nov 28 21:45:21 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 202558 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 CA7AE2C0080 for ; Thu, 29 Nov 2012 08:45:37 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1354743940; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Mail-Followup-To:Cc:Subject:References:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=+olrUAlkwO0Pb8x9lraM QOyuy9g=; b=Rl9LUNVkZ+RQloRE82Ucz4VuXACpOvF4qsGE+OUpOTBq9inFyiul odx1Cd0x6zQeOrcqzmOxEModCfquZTKJExhSV2YOgNL0Q6DQwna3MmFBF6IgDoes ctjmmz16DaUs5TdEp9iFadfssz2rCayXgMZd7XfQzIn55Uyo6AScS/4= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:From:To:Mail-Followup-To:Cc:Subject:References:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=xvEyXVP0bNZjj94WmQK92eZqSgYt+15sVXinWc36Gixsn+Ni54R9yxYX4i1D+b L6r8+E9YiLr+ASu2UHCyj3eSsCTMUI992AD/oIAqvQj2+OTeAysp7Fp/GT90z/m4 BZS4DVgYVy4accFo4eglmHM/tDPZ65/vyp5vlQiOdzlck=; Received: (qmail 19229 invoked by alias); 28 Nov 2012 21:45:32 -0000 Received: (qmail 19218 invoked by uid 22791); 28 Nov 2012 21:45:32 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL, BAYES_50, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, KHOP_RCVD_TRUST, NML_ADSP_CUSTOM_MED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Nov 2012 21:45:25 +0000 Received: by mail-wi0-f179.google.com with SMTP id hj6so4626035wib.8 for ; Wed, 28 Nov 2012 13:45:24 -0800 (PST) Received: by 10.216.82.139 with SMTP id o11mr7167257wee.105.1354139124435; Wed, 28 Nov 2012 13:45:24 -0800 (PST) Received: from localhost ([2.28.234.219]) by mx.google.com with ESMTPS id i6sm8700405wix.5.2012.11.28.13.45.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Nov 2012 13:45:23 -0800 (PST) From: Richard Sandiford To: ramrad01@arm.com Mail-Followup-To: ramrad01@arm.com, Eric Botcazou , gcc-patches@gcc.gnu.org, Andrew Pinski , Uros Bizjak , Paul_Koning@dell.com, kkojima@gcc.gnu.org, aoliva@redhat.com, dje.gcc@gmail.com, uweigand@de.ibm.com, walt@tilera.com, rdsandiford@googlemail.com Cc: Eric Botcazou , gcc-patches@gcc.gnu.org, Andrew Pinski , Uros Bizjak , Paul_Koning@dell.com, kkojima@gcc.gnu.org, aoliva@redhat.com, dje.gcc@gmail.com, uweigand@de.ibm.com, walt@tilera.com Subject: Re: RFA: Simplifying truncation and integer lowpart subregs References: <6083166.IsGSDDFhFR@polaris> <87fw5rojui.fsf@talisman.home> <7298988.0gvUXNUO8B@polaris> <874nm6oe2n.fsf@talisman.home> Date: Wed, 28 Nov 2012 21:45:21 +0000 In-Reply-To: (Ramana Radhakrishnan's message of "Wed, 28 Nov 2012 02:27:11 +0000") Message-ID: <87boehmmfi.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.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 Ramana Radhakrishnan writes: > On Sun, Oct 7, 2012 at 8:56 AM, Richard Sandiford > wrote: >> Eric Botcazou writes: >>>> I think modelling it as a TRUNCATE operation is correct for >>>> !TRULY_NOOP_TRUNCATION (it's the bug that Andrew pointed out). >>>> And we shouldn't generate an actual TRUNCATE rtx for >>>> TRULY_NOOP_TRUNCATION (the thing about making >>>> simplify_gen_unary (TRUNCATE, ...) no worse than simplify_gen_subreg >>>> for those targets). I suppose: >>>> >>>> /* We can't handle truncation to a partial integer mode here >>>> because we don't know the real bitsize of the partial >>>> integer mode. */ >>>> if (GET_MODE_CLASS (mode) == MODE_PARTIAL_INT) >>>> break; >>>> >>>> might be a problem though; we should still allow a subreg to be >>>> generated. Is that what you were thinking of, or something else? >>> >>> I was thinking of the !TRULY_NOOP_TRUNCATION case, where the two operations >>> aren't equivalent. Generating TRUNCATE in simplify_subreg seems >>> suspicious to >>> me in this case but, if not doing it is the source of the bug, I guess I need >>> to do some homework on this TRULY_NOOP_TRUNCATION stuff. :-) >>> >>> Maybe add a blurb to the head comment of simplify_truncation, explaining that >>> it is valid to call the function both for TRUNCATEs and truncations to the >>> lowpart, and why it is correct to generate new TRUNCATEs in the latter case. >> >> Yeah, in hindsight, the patch was definitely lacking commentary. >> How about the patch below? It also fixes the partial int case >> and gets rid of the errant NOT hunk. Tested in the same way as before. >> >> Richard >> >> >> gcc/ >> * machmode.h (GET_MODE_UNIT_PRECISION): New macro. >> * simplify-rtx.c (simplify_truncation): New function, >> extracted from simplify_subreg and (in small part) from >> simplify_unary_operation_1. >> (simplify_unary_operation_1) : Use it. Remove sign bit >> test for !TRULY_NOOP_TRUNCATION_MODES_P. >> (simplify_subreg): Use simplify_truncate for lowpart subregs >> where both the inner and outer modes are scalar integers. >> * config/mips/mips.c (mips_truncated_op_cost): New function. >> (mips_rtx_costs): Adjust test for BADDU. >> * config/mips/mips.md (*baddu_di): Push truncates to operands. > > This triggers PR55052 on ARM.I've attached the .i file and the dumps > to the bug report. Thanks. I'd managed to drop a SCALAR_INT_MODE_P check when splitting the ZERO_EXTEND handling into two. This patch reinstates the check. Tested on x86_64-linux-gnu and applied as obvious. Richard gcc/ PR rtl-optimization/55052 * simplify-rtx.c (simplify_subreg): Restore SCALAR_INT_MODE_P check. Index: gcc/simplify-rtx.c =================================================================== --- gcc/simplify-rtx.c 2012-11-27 18:52:29.000000000 +0000 +++ gcc/simplify-rtx.c 2012-11-28 19:54:30.500525576 +0000 @@ -5875,7 +5875,7 @@ simplify_subreg (enum machine_mode outer /* A SUBREG resulting from a zero extension may fold to zero if it extracts higher bits that the ZERO_EXTEND's source bits. */ - if (GET_CODE (op) == ZERO_EXTEND) + if (GET_CODE (op) == ZERO_EXTEND && SCALAR_INT_MODE_P (innermode)) { unsigned int bitpos = subreg_lsb_1 (outermode, innermode, byte); if (bitpos >= GET_MODE_PRECISION (GET_MODE (XEXP (op, 0)))