From patchwork Thu Mar 15 16:46:34 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulrich Weigand X-Patchwork-Id: 7314 Return-Path: X-Original-To: patchwork@peony.canonical.com Delivered-To: patchwork@peony.canonical.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by peony.canonical.com (Postfix) with ESMTP id E155423E01 for ; Thu, 15 Mar 2012 16:46:47 +0000 (UTC) Received: from mail-iy0-f180.google.com (mail-iy0-f180.google.com [209.85.210.180]) by fiordland.canonical.com (Postfix) with ESMTP id 8E3A2A18563 for ; Thu, 15 Mar 2012 16:46:47 +0000 (UTC) Received: by iage36 with SMTP id e36so5520681iag.11 for ; Thu, 15 Mar 2012 09:46:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-forwarded-to:x-forwarded-for:delivered-to:received-spf:message-id :subject:to:date:from:x-mailer:mime-version:content-type :content-transfer-encoding:x-cbid:x-gm-message-state; bh=AnBYgMtK8Qt1s46v5j456jASCgMFFvk1+oNKHEbrcGo=; b=T6Hw1Wbn0Yp3Z2Q02e+Cqw670VjO5Cy0cejq/8FShcEXvxbntY1DgG6FZBqK6Go9oV WrpvUu5MC3wLsW1zpCIbjMVmZtsBqjDdg468KOUalzYEAZbtBgO2Df4UJAU5WFvxiwkb PHa/1HrNbXwns+O3jO5fR9AnFZ0t/yQ87uL5MrQooHCZlRY2jYa19tqX5WnSSb86mPVN gVhhQTIjYgMjLE60p/qAytYoUJE4Ag0iSm64vywjwqumv3Ce2xbyHz1jxnv6YTO1KTmR DzqpvVPQTIjXDUrmYmLQR+v8ykQbpYkR2wFHyUZSPv1Sa1GtV0V0DYUWDt8UB37fsKhM IaGw== Received: by 10.50.159.135 with SMTP id xc7mr10438591igb.50.1331830006974; Thu, 15 Mar 2012 09:46:46 -0700 (PDT) X-Forwarded-To: linaro-patchwork@canonical.com X-Forwarded-For: patch@linaro.org linaro-patchwork@canonical.com Delivered-To: patches@linaro.org Received: by 10.231.53.18 with SMTP id k18csp41127ibg; Thu, 15 Mar 2012 09:46:45 -0700 (PDT) Received: by 10.180.105.69 with SMTP id gk5mr32283125wib.3.1331830005161; Thu, 15 Mar 2012 09:46:45 -0700 (PDT) Received: from e06smtp17.uk.ibm.com (e06smtp17.uk.ibm.com. [195.75.94.113]) by mx.google.com with ESMTPS id v8si3131911wid.22.2012.03.15.09.46.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 09:46:45 -0700 (PDT) Received-SPF: pass (google.com: domain of uweigand@de.ibm.com designates 195.75.94.113 as permitted sender) client-ip=195.75.94.113; Authentication-Results: mx.google.com; spf=pass (google.com: domain of uweigand@de.ibm.com designates 195.75.94.113 as permitted sender) smtp.mail=uweigand@de.ibm.com Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Mar 2012 16:46:44 -0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (9.149.38.233) by e06smtp17.uk.ibm.com (192.168.101.147) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 15 Mar 2012 16:46:36 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2FGkafQ2392140 for ; Thu, 15 Mar 2012 16:46:36 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 q2FGkaYQ025073 for ; Thu, 15 Mar 2012 10:46:36 -0600 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 q2FGkYZc025028 for ; Thu, 15 Mar 2012 10:46:34 -0600 Message-Id: <201203151646.q2FGkYZc025028@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 15 Mar 2012 17:46:34 +0100 Subject: [PATCH] Do not handle SUBREG in apply_distributive_law (Re: RFC: allowing fwprop to propagate subregs) To: patches@linaro.org Date: Thu, 15 Mar 2012 17:46:34 +0100 (CET) From: "Ulrich Weigand" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 x-cbid: 12031516-0542-0000-0000-000001470009 X-Gm-Message-State: ALoCoQkyISiQ1wOBgC/2MwdBS9m1wbNKV2pOllw0zpJCRUytQy30bsjTXUbK9YjVSmjo+wcEfNbA http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00518.html 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;