From patchwork Wed Mar 7 17:40:04 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulrich Weigand X-Patchwork-Id: 145321 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 82CDEB6EEA for ; Thu, 8 Mar 2012 04:40:36 +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=1331746837; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Received:Message-Id:Received:Subject:To:Date: From:Cc:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=Dy1d1ocDucn9i4aF235xw3zE3xw=; b=XUlU1GgGTeH3wvJ 4wzt79gTjR1lHgsLamJHUuCprTd4LnYwRoPpD4bqSpt06SM2P40HT3a2dSLMUpwZ PukEszuB4YE33kojw7z5n5nZls8Wmd7Wl1Jab8mlz/qizBQOKIZxNn7nA/VHk63X tjZAJ/jXZlHdi0JXcydYLhM7bAzg= 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:Received:Received:Message-Id:Received:Subject:To:Date:From:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:x-cbid:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=QgBvaeGwdhqooJPkbL2mLP6WDGOEwhNe4u8T13SRqNXnsmSfAsBb0hHgP1PLGp e+YBwMS2KET/ZhYfKQsTYSc/1zgv5Ocmymm1KYUZDEN6HW3L/BfUbC/0uvfnup9+ KCUoRa2Ou3mVtlbUtXYaYYUrMr7tzFScohqqbdN22rpPA=; Received: (qmail 22381 invoked by alias); 7 Mar 2012 17:40:33 -0000 Received: (qmail 22366 invoked by uid 22791); 7 Mar 2012 17:40:32 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL, BAYES_00, MSGID_FROM_MTA_HEADER, TW_FW, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e06smtp10.uk.ibm.com (HELO e06smtp10.uk.ibm.com) (195.75.94.106) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Mar 2012 17:40:09 +0000 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Mar 2012 17:40:08 -0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (9.149.38.185) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 7 Mar 2012 17:40:07 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q27He6SC2207880 for ; Wed, 7 Mar 2012 17:40:06 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q27He6JI009424 for ; Wed, 7 Mar 2012 10:40:06 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id q27He4YE009342; Wed, 7 Mar 2012 10:40:05 -0700 Message-Id: <201203071740.q27He4YE009342@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 07 Mar 2012 18:40:04 +0100 Subject: [PATCH] Do not handle SUBREG in apply_distributive_law (Re: RFC: allowing fwprop to propagate subregs) To: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Date: Wed, 7 Mar 2012 18:40:04 +0100 (CET) From: "Ulrich Weigand" Cc: bonzini@gnu.org, gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org In-Reply-To: <11201171958.AA09076@vlsi1.ultra.nyu.edu> from "Richard Kenner" at Jan 17, 2012 02:58:50 PM MIME-Version: 1.0 x-cbid: 12030717-4966-0000-0000-000001AE140F 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 Richard Kenner wrote: > > Given the current set of results, since I do not have any way to verify > > whether my simplify_set changes would actually trigger correctly, I'd > > rather propose to just remove the SUBREG case in apply_distributive_law > > (i.e. only apply the first patch below). > > > > Thoughts? > > I think that's reasonable. But I'd replace it with a comment saying > what used to be there and why it was removed. Now that we're back in stage 1, I'd like to try and move forward with this again. Here's a patch that implements your suggestion. Tested on arm-linux-gnueabi, i386-linux-gnu and s390-linux-gnu. OK for mainline? Bye, Ulrich 2012-03-07 Ulrich Weigand gcc/ * combine.c (apply_distributive_law): Do not distribute SUBREG. === modified file 'gcc/combine.c' --- gcc/combine.c 2012-02-07 15:48:52 +0000 +++ gcc/combine.c 2012-02-22 11:57:19 +0000 @@ -9286,36 +9286,22 @@ /* This is also a multiply, so it distributes over everything. */ break; - case SUBREG: - /* Non-paradoxical SUBREGs distributes over all operations, - provided the inner modes and byte offsets are the same, this - is an extraction of a low-order part, we don't convert an fp - operation to int or vice versa, this is not a vector mode, - and we would not be converting a single-word operation into a - multi-word operation. The latter test is not required, but - it prevents generating unneeded multi-word operations. Some - of the previous tests are redundant given the latter test, - but are retained because they are required for correctness. - - We produce the result slightly differently in this case. */ - - if (GET_MODE (SUBREG_REG (lhs)) != GET_MODE (SUBREG_REG (rhs)) - || SUBREG_BYTE (lhs) != SUBREG_BYTE (rhs) - || ! subreg_lowpart_p (lhs) - || (GET_MODE_CLASS (GET_MODE (lhs)) - != GET_MODE_CLASS (GET_MODE (SUBREG_REG (lhs)))) - || paradoxical_subreg_p (lhs) - || VECTOR_MODE_P (GET_MODE (lhs)) - || GET_MODE_SIZE (GET_MODE (SUBREG_REG (lhs))) > UNITS_PER_WORD - /* Result might need to be truncated. Don't change mode if - explicit truncation is needed. */ - || !TRULY_NOOP_TRUNCATION_MODES_P (GET_MODE (x), - GET_MODE (SUBREG_REG (lhs)))) - return x; - - tem = simplify_gen_binary (code, GET_MODE (SUBREG_REG (lhs)), - SUBREG_REG (lhs), SUBREG_REG (rhs)); - return gen_lowpart (GET_MODE (x), tem); + /* This used to handle SUBREG, but this turned out to be counter- + productive, since (subreg (op ...)) usually is not handled by + insn patterns, and this "optimization" therefore transformed + recognizable patterns into unrecognizable ones. Therefore the + SUBREG case was removed from here. + + It is possible that distributing SUBREG over arithmetic operations + leads to an intermediate result than can then be optimized further, + e.g. by moving the outer SUBREG to the other side of a SET as done + in simplify_set. This seems to have been the original intent of + handling SUBREGs here. + + However, with current GCC this does not appear to actually happen, + at least on major platforms. If some case is found where removing + the SUBREG case here prevents follow-on optimizations, distributing + SUBREGs ought to be re-added at that place, e.g. in simplify_set. */ default: return x;