From patchwork Fri Dec 7 15:52:21 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 1009528 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-491900-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="U7dEv7XH"; 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 43BH6W02Wkz9s0n for ; Sat, 8 Dec 2018 02:52:33 +1100 (AEDT) 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=CV9JL/Hm1yDkbABwMLjknVaHqezMTn5lSiGQX9Xw9ryKdWffueups r/eCiKFhDR03DiUQajmk5A066ldgsRk8M/xBaAQGoEigXzUK/hHIXvmmsWJPc0OQ UPEGwoslnBM/F0scXPlnaUZBHjEWIGlq5Hy1atvnk7hw2k/WW4hAQ8= 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=zQztFZBoHssX//7xWPQMWPtJRkU=; b=U7dEv7XHGA+5ZrWkHxRD X2sMaiPM4chwf4X2u3bAAbHC2XZ9gADd9vCsFKosR79pTHMI/kIHYh9shxNBYQ5g ysoDK5+m7rUCJ9bIZnnt61h3UtmySSDO/CtXLbKvkbdlKtX6vubjOiEF+E7wG02Z +X4YHZeuVW7dJvDFNZth/PI= Received: (qmail 21912 invoked by alias); 7 Dec 2018 15:52:26 -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 21902 invoked by uid 89); 7 Dec 2018 15:52:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=gpi, ulc, rejects, Prefer 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; Fri, 07 Dec 2018 15:52:24 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7CEB74E92A; Fri, 7 Dec 2018 15:52:23 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-17.rdu2.redhat.com [10.10.112.17]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6F2965DD85; Fri, 7 Dec 2018 15:52:22 +0000 (UTC) From: Jeff Law Openpgp: preference=signencrypt To: gcc-patches , Richard Earnshaw , James Greenhalgh Subject: [RFA] [target/87369] Prefer "bit" over "bfxil" Message-ID: Date: Fri, 7 Dec 2018 08:52:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 X-IsSubscribed: yes As I suggested in the BZ, this patch rejects constants with just the high bit set for the recently added "bfxil" pattern. As a result we'll return to using "bit" for the test in the BZ. I'm not versed enough in aarch64 performance tuning to know if "bit" is actually a better choice than "bfxil". "bit" results in better code for the testcase, but that seems more a function of register allocation than "bit" being inherently better than "bfxil". Obviously someone with more aarch64 knowledge needs to make a decision here. My first iteration of the patch changed "aarch64_high_bits_all_ones_p". We could still go that way too, though the name probably needs to change. I've bootstrapped and regression tested on aarch64-linux-gnu and it fixes the regression. I've also bootstrapped aarch64_be-linux-gnu, but haven't done any kind of regression tested on that platform. OK for the trunk? Jeff PR target/87369 * config/aarch64/aarch64.md (aarch64_bfxil): Do not accept constant with just the high bit set. That's better handled by the "bit" pattern. diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md index 88f66104db3..ad6822410c2 100644 --- a/gcc/config/aarch64/aarch64.md +++ b/gcc/config/aarch64/aarch64.md @@ -5342,9 +5342,11 @@ (match_operand:GPI 3 "const_int_operand" "n, Ulc")) (and:GPI (match_operand:GPI 2 "register_operand" "0,r") (match_operand:GPI 4 "const_int_operand" "Ulc, n"))))] - "(INTVAL (operands[3]) == ~INTVAL (operands[4])) - && (aarch64_high_bits_all_ones_p (INTVAL (operands[3])) - || aarch64_high_bits_all_ones_p (INTVAL (operands[4])))" + "(INTVAL (operands[3]) == ~INTVAL (operands[4]) + && ((aarch64_high_bits_all_ones_p (INTVAL (operands[3])) + && popcount_hwi (INTVAL (operands[3])) != 1) + || (aarch64_high_bits_all_ones_p (INTVAL (operands[4])) + && popcount_hwi (INTVAL (operands[4])) != 1)))" { switch (which_alternative) {