From patchwork Tue Apr 8 19:07:25 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bill Schmidt X-Patchwork-Id: 337722 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 0CD121400AA for ; Wed, 9 Apr 2014 05:07:36 +1000 (EST) 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:subject:from:to:cc:date:content-type :content-transfer-encoding:mime-version; q=dns; s=default; b=WQB Dw0EPD8FotwWDPixjK95gTl9N/JjB14DpLwZ4wsXu8Ynzgin9rkvE6eGOBkFpHb8 vwgDfdohvToZNyVHnZcF5OZP/fyBVcrwIA01B6FuKSkcnLBSU3G1CXxYlZCxbNZe PzGOmWvBMKmnGkxs6wOeZqljtsteYNHCXZ7NDPWo= 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:subject:from:to:cc:date:content-type :content-transfer-encoding:mime-version; s=default; bh=KlBC3uY2e Rv9RPHa1g5Yc6XffOM=; b=j4cKrguEXAFNT2n2Ltkxuon21Bx9V7IWfq36VdGK0 BEEOfps82jwk1jbWMA8P+I7+HQJQG+ezDhG3FnyowOWy+gQfCMqihVpeVEkIonAo pB0b21Vjrhs1ziqbH9DzO3rOmv8KXUUhv8bpgKF3sJDFY3eflLLQqlGFZlGw8SNh P0= Received: (qmail 22840 invoked by alias); 8 Apr 2014 19:07:28 -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 22828 invoked by uid 89); 8 Apr 2014 19:07:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e38.co.us.ibm.com Received: from e38.co.us.ibm.com (HELO e38.co.us.ibm.com) (32.97.110.159) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 08 Apr 2014 19:07:25 +0000 Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 8 Apr 2014 13:07:23 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 8 Apr 2014 13:07:22 -0600 Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id DE5123E40040 for ; Tue, 8 Apr 2014 13:07:21 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by b03cxnp07029.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s38H4NRj11731288 for ; Tue, 8 Apr 2014 19:04:23 +0200 Received: from d03av01.boulder.ibm.com (localhost [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s38J7LjG002021 for ; Tue, 8 Apr 2014 13:07:21 -0600 Received: from [9.76.129.59] (sig-9-76-129-59.mts.ibm.com [9.76.129.59]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s38J7KqK001959; Tue, 8 Apr 2014 13:07:21 -0600 Message-ID: <1396984045.5401.125.camel@gnopaine> Subject: [PATCH, rs6000] Prefer vnand/vperm over vnor/vperm for Power8 From: Bill Schmidt To: gcc-patches@gcc.gnu.org Cc: dje.gcc@gmail.com Date: Tue, 08 Apr 2014 14:07:25 -0500 Mime-Version: 1.0 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14040819-1344-0000-0000-000000CCF263 X-IsSubscribed: yes Hi, Recently I posted a patch to use vnor to invert the permute control vector for little-endian permutes. It's come to my attention that, when available, the vnand instruction should be used in preference to vnor for possible future processor exploitation. This patch checks for availability of vnand and uses it instead. It also removes earlier use of emit_move_insn in this logic where that was not appropriate. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions. Is this ok for trunk? I would also like to backport the combined patch to the FSF 4.8 branch, if you feel that is appropriate. Please let me know. Thanks, Bill 2014-04-08 Bill Schmidt * config/rs6000/rs6000.c (rs6000_expand_vector_set): Use vnand instead of vnor to exploit possible fusion opportunity in the future. (altivec_expand_vec_perm_const_le): Likewise. Index: gcc/config/rs6000/rs6000.c =================================================================== --- gcc/config/rs6000/rs6000.c (revision 209205) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -5635,11 +5635,15 @@ rs6000_expand_vector_set (rtx target, rtx val, int UNSPEC_VPERM); else { - /* Invert selector. */ + /* Invert selector. We prefer to generate VNAND on P8 so + that future fusion opportunities can kick in, but must + generate VNOR elsewhere. */ rtx notx = gen_rtx_NOT (V16QImode, force_reg (V16QImode, x)); - rtx andx = gen_rtx_AND (V16QImode, notx, notx); + rtx iorx = (TARGET_P8_VECTOR + ? gen_rtx_IOR (V16QImode, notx, notx) + : gen_rtx_AND (V16QImode, notx, notx)); rtx tmp = gen_reg_rtx (V16QImode); - emit_move_insn (tmp, andx); + emit_insn (gen_rtx_SET (VOIDmode, tmp, iorx)); /* Permute with operands reversed and adjusted selector. */ x = gen_rtx_UNSPEC (mode, gen_rtvec (3, reg, target, tmp), @@ -30212,12 +30216,12 @@ altivec_expand_vec_perm_const_le (rtx operands[4]) /* Similarly to altivec_expand_vec_perm_const_le, we must adjust the permute control vector. But here it's not a constant, so we must - generate a vector NOR to do the adjustment. */ + generate a vector NAND or NOR to do the adjustment. */ void altivec_expand_vec_perm_le (rtx operands[4]) { - rtx notx, andx, unspec; + rtx notx, iorx, unspec; rtx target = operands[0]; rtx op0 = operands[1]; rtx op1 = operands[2]; @@ -30236,10 +30240,13 @@ altivec_expand_vec_perm_le (rtx operands[4]) if (!REG_P (target)) tmp = gen_reg_rtx (mode); - /* Invert the selector with a VNOR. */ + /* Invert the selector with a VNAND if available, else a VNOR. + The VNAND is preferred for future fusion opportunities. */ notx = gen_rtx_NOT (V16QImode, sel); - andx = gen_rtx_AND (V16QImode, notx, notx); - emit_move_insn (norreg, andx); + iorx = (TARGET_P8_VECTOR + ? gen_rtx_IOR (V16QImode, notx, notx) + : gen_rtx_AND (V16QImode, notx, notx)); + emit_insn (gen_rtx_SET (VOIDmode, norreg, iorx)); /* Permute with operands reversed and adjusted selector. */ unspec = gen_rtx_UNSPEC (mode, gen_rtvec (3, op1, op0, norreg),