From patchwork Thu Dec 10 14:36:05 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kyrylo Tkachov X-Patchwork-Id: 58220 Delivered-To: patch@linaro.org Received: by 10.112.147.194 with SMTP id tm2csp531333lbb; Thu, 10 Dec 2015 06:36:29 -0800 (PST) X-Received: by 10.66.140.39 with SMTP id rd7mr17042010pab.86.1449758189725; Thu, 10 Dec 2015 06:36:29 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id c85si20681941pfj.62.2015.12.10.06.36.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Dec 2015 06:36:29 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-return-416963-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; spf=pass (google.com: domain of gcc-patches-return-416963-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-416963-patch=linaro.org@gcc.gnu.org; dkim=pass header.i=@gcc.gnu.org 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:content-type; q=dns; s=default; b=QSXJxuzg+L/vSmRkW16FPkNc0z30kDYjmArf2HGkJdC VhZRv2Y+iRcszo8ODhnDbimfgahY9CcE3Sxc4eIc+2aI26kzJoZzJ0NMfxZnUXmP 5cWL+rdOpDyco17zLYH/gfbB+bsQ2MOIj7kBBLIX4nG1MsNh33aDLp6SvCTn3JIs = 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:content-type; s=default; bh=wDLll56SCa4nYPCjFAXqiOT1K8c=; b=F4C6kq6NFA//u3Rbs Wr7hpSmBBa4DnskqR4uuClOydF3N6PGJcoW/mZ9OyZ0aDpif9zKiIyNrLsmJKz7x lv/eZK75hM/0D13KY2b/HnmaYLGTqpqxd07YdEc/qrT4yvZEZaXSJXkS7uGtJQ6Q EimNj7xET/tM1I7aPfV8ZSMT8k= Received: (qmail 69950 invoked by alias); 10 Dec 2015 14:36:15 -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 69935 invoked by uid 89); 10 Dec 2015 14:36:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL, BAYES_00, SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Dec 2015 14:36:13 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-10-ylObqTRYQOuk45rw-riqBg-1; Thu, 10 Dec 2015 14:36:06 +0000 Received: from [10.2.206.200] ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2015 14:36:05 +0000 Message-ID: <56698DD5.3010105@arm.com> Date: Thu, 10 Dec 2015 14:36:05 +0000 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: GCC Patches CC: Segher Boessenkool Subject: [PATCH][combine] Don't create LSHIFTRT of zero bits in change_zero_ext X-MC-Unique: ylObqTRYQOuk45rw-riqBg-1 X-IsSubscribed: yes Hi all, At the end of combine if it fails to recognise the patterns it produces it tries again after transforming all zero_extends and zero_extracts into and-immediate plus an LSHIFTRT if needed. However, it will construct an LSHIFTRT inside the AND even if the shift distance is 0, which can hurt recognisability. This patch fixes that by not creating the LSHIFRT of zero. I hit this when I was experimenting with some new backend patterns and other unrelated combine changes, so I don't have a testcase that shows this on a clean trunk, but I believe this could hurt recognisability in the future. Bootstrapped and tested on arm, aarch64, x86_64. I didn't see any codegen differences with clean trunk on aarch64 SPEC2006. I'm okay with delaying this for next stage 1 if people prefer, though I think it's pretty low risk. What do people think? Kyrill 2015-12-10 Kyrylo Tkachov * combine.c (change_zero_ext): Do not create a shift of zero length. diff --git a/gcc/combine.c b/gcc/combine.c index 7d4ffbcc766113c0af1c903f3d0dadbe74dec7fa..2628e1a437c2cd63d439a3ad28d1799b8c679be3 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -11037,7 +11037,9 @@ change_zero_ext (rtx *src) if (BITS_BIG_ENDIAN) start = GET_MODE_PRECISION (mode) - size - start; - x = gen_rtx_LSHIFTRT (mode, XEXP (x, 0), GEN_INT (start)); + x = XEXP (x, 0); + if (start > 0) + x = gen_rtx_LSHIFTRT (mode, x, GEN_INT (start)); } else if (GET_CODE (x) == ZERO_EXTEND && GET_CODE (XEXP (x, 0)) == SUBREG