From patchwork Mon Apr 15 15:50:15 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 1085719 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-499268-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="NfI/aWov"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 44jXyZ2BDtz9s71 for ; Tue, 16 Apr 2019 01:50:28 +1000 (AEST) 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:subject:message-id:date:mime-version:content-type; q=dns; s= default; b=ujLEiK60VXGaxcFmH+yNG6yYryQyXXRHY06GkRa5DqIX5jNOVPcia Bd0Ous/gQTC1nfuJlxYtCweY95jEEYi/v6EHttH/1m7/mR4+g2ejacIxPnKyYz3D qmmUJbVwQQP9R5ZXVGWIaHmwsVW9yjJLTWE/irfb2wn3+b4Y5NiL/k= 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:subject:message-id:date:mime-version:content-type; s= default; bh=pB/eqXKnHMwYSQnRtOK4NE7yTfQ=; b=NfI/aWova53YlFt1GlOW oUJx5/o3dZSj+DKF/DFjjD/TXV/Ux2UC+m7v+wy2Au+EXheq+mMDKM6xPHYhpuD8 /yToK1UPGz/D+/wgJ0oe/3H2+SlCaA2EsgOSWiYUXQ6AHp6s4EfJtgs1lWUPs/NU znFYwsBkAThLnwV9TGVDGis= Received: (qmail 3264 invoked by alias); 15 Apr 2019 15:50:20 -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 3248 invoked by uid 89); 15 Apr 2019 15:50:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_NUMSUBJECT, SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=manner, encourage, LRA, lra X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Apr 2019 15:50:19 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 385E4C05E760 for ; Mon, 15 Apr 2019 15:50:18 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-8.rdu2.redhat.com [10.10.112.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id A21F75D717 for ; Mon, 15 Apr 2019 15:50:16 +0000 (UTC) From: Jeff Law Openpgp: preference=signencrypt To: gcc-patches Subject: [aarch64][RFA/RFC][rtl-optimization/87763] Add new movk pattern for aarch64 Message-ID: <774c6e64-117d-c146-852b-612ff4ab1085@redhat.com> Date: Mon, 15 Apr 2019 09:50:15 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 X-IsSubscribed: yes Here's my attempt to fix the movk regression on bz 87763. I still wonder if addressing some of these issues in combine is a better long term solution, but in the immediate term I think backend patterns are going to have to be the way to go. This introduces a new insn_and_split that matches a movk via the ior..and form. We rewrite it back into the zero-extract form once operands0 and operands1 match. This allows insn fusion in the scheduler to work as it expects the zero-extract form. While I have bootstrapped this on aarch64 and aarch64_be, I haven't done anything with ILP32. On aarch64 I have also run this through a regression test cycle where it fixes the movk regression identified in bz87763. Thoughts? If we're generally happy with this direction I can look to tackle the insv_1 and insv_2 regressions in a similar manner. Jeff * config/aarch64/aarch64.md: Add new pattern matching movk field insertion via (and (ior ...)). diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md index ab8786a933e..109694f9ef0 100644 --- a/gcc/config/aarch64/aarch64.md +++ b/gcc/config/aarch64/aarch64.md @@ -1161,6 +1161,54 @@ [(set_attr "type" "mov_imm")] ) +;; This is for the combiner to use to encourage creation of +;; bitfield insertions using movk. +;; +;; We rewrite back into a movk bitfield insertion to make sched +;; fusion happy the first chance we get where the appropriate +;; operands match. After LRA they should always match. +(define_insn_and_split "" + [(set (match_operand:GPI 0 "register_operand" "=r") + (ior:GPI (and:GPI (match_operand:GPI 1 "register_operand" "0") + (match_operand:GPI 2 "const_int_operand" "n")) + (match_operand:GPI 3 "const_int_operand" "n")))] + "((UINTVAL (operands[2]) == 0xffffffffffff0000 + || UINTVAL (operands[2]) == 0xffffffff0000ffff + || UINTVAL (operands[2]) == 0xffff0000ffffffff + || UINTVAL (operands[2]) == 0x0000ffffffffffff) + && (UINTVAL (operands[2]) & UINTVAL (operands[3])) == 0)" + "#" + "&& rtx_equal_p (operands[0], operands[1])" + [(set (zero_extract: (match_dup 0) + (const_int 16) + (match_dup 2)) + (match_dup 3))] + "{ + if (UINTVAL (operands[2]) == 0xffffffffffff0000) + { + operands[2] = GEN_INT (0); + operands[3] = GEN_INT (UINTVAL (operands[3]) & 0xffff); + } + else if (UINTVAL (operands[2]) == 0xffffffff0000ffff) + { + operands[2] = GEN_INT (16); + operands[3] = GEN_INT ((UINTVAL (operands[3]) >> 16) & 0xffff); + } + else if (UINTVAL (operands[2]) == 0xffff0000ffffffff) + { + operands[2] = GEN_INT (32); + operands[3] = GEN_INT ((UINTVAL (operands[3]) >> 32) & 0xffff); + } + else if (UINTVAL (operands[2]) == 0x0000ffffffffffff) + { + operands[2] = GEN_INT (48); + operands[3] = GEN_INT ((UINTVAL (operands[3]) >> 48) & 0xffff); + } + else + gcc_unreachable (); + }" +) + (define_expand "movti" [(set (match_operand:TI 0 "nonimmediate_operand" "") (match_operand:TI 1 "general_operand" ""))]