From patchwork Fri Jun 29 05:54:33 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 167985 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]) by ozlabs.org (Postfix) with SMTP id 0C9911007D4 for ; Fri, 29 Jun 2012 15:55:10 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1341554112; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:User-Agent:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=OmS6EhSy4HucbURLN3KZYLeqjWw=; b=RAGOgRvLSbXNBDW nSe7pQyIaCeSwH34Ur96PbOyMRtQ15G9eBMOrq8GVWK6QSugm8wV07pUQPEiojef kkndCModKogjgp1r6T4Qh+pr5yN5QjD11qEtOnD27kI+cQmTSQPWZdrbaog1X5XT vsSRf5T2PUHxx43I7dups9NpPsTw= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=ujXxVFMylG5N5ScYbRON+LqGC/NZ8eq+OwUW8XBz036QXHAT24WY4UIg4DTkYp rwC8zYu+jXRN+mAHzuYrwYoR9z3wcNqgpJM/xYeBD1ysidzUPO9QRpL0oRJj50uE a4hTYiMojnRzW+miFR/YLg73Bk2VxUGx8fQb/Tzldqp78=; Received: (qmail 29337 invoked by alias); 29 Jun 2012 05:54:53 -0000 Received: (qmail 29323 invoked by uid 22791); 29 Jun 2012 05:54:51 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 29 Jun 2012 05:54:37 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5T5sbSD016719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jun 2012 01:54:37 -0400 Received: from zalov.redhat.com (vpn1-7-241.ams2.redhat.com [10.36.7.241]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q5T5sZQG019487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 01:54:36 -0400 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id q5T5sXhJ031938; Fri, 29 Jun 2012 07:54:34 +0200 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id q5T5sXDL031937; Fri, 29 Jun 2012 07:54:33 +0200 Date: Fri, 29 Jun 2012 07:54:33 +0200 From: Jakub Jelinek To: Bernhard Reutner-Fischer Cc: Richard Henderson , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Add MULT_HIGHPART_EXPR Message-ID: <20120629055433.GW20264@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <1340833028-3712-1-git-send-email-rth@redhat.com> <20120628071755.GP20264@tucnak.redhat.com> <20120628140558.GS20264@tucnak.redhat.com> <20120628220010.GA5161@mx.loc> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120628220010.GA5161@mx.loc> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 On Fri, Jun 29, 2012 at 12:00:10AM +0200, Bernhard Reutner-Fischer wrote: > Really both HI? If so optab2 could be removed from that fn altogether.. Of course, thanks for pointing that out. I've additionally added a result mode check (similar to what supportable_widening_operation does). The reason for not using supportable_widening_operation is that it only tests even/odd calls for reductions, while we can use them everywhere. Committed as obvious. 2012-06-29 Jakub Jelinek * tree-vect-stmts.c (vectorizable_operation): Check both VEC_WIDEN_MULT_LO_EXPR and VEC_WIDEN_MULT_HI_EXPR optabs. Verify that operand[0]'s mode is TYPE_MODE (wide_vectype). Jakub --- gcc/tree-vect-stmts.c (revision 189053) +++ gcc/tree-vect-stmts.c (working copy) @@ -3504,14 +3504,19 @@ vectorizable_operation (gimple stmt, gim { decl1 = NULL_TREE; decl2 = NULL_TREE; - optab = optab_for_tree_code (VEC_WIDEN_MULT_HI_EXPR, + optab = optab_for_tree_code (VEC_WIDEN_MULT_LO_EXPR, vectype, optab_default); optab2 = optab_for_tree_code (VEC_WIDEN_MULT_HI_EXPR, vectype, optab_default); if (optab != NULL && optab2 != NULL && optab_handler (optab, vec_mode) != CODE_FOR_nothing - && optab_handler (optab2, vec_mode) != CODE_FOR_nothing) + && optab_handler (optab2, vec_mode) != CODE_FOR_nothing + && insn_data[optab_handler (optab, vec_mode)].operand[0].mode + == TYPE_MODE (wide_vectype) + && insn_data[optab_handler (optab2, + vec_mode)].operand[0].mode + == TYPE_MODE (wide_vectype)) { for (i = 0; i < nunits_in; i++) sel[i] = !BYTES_BIG_ENDIAN + 2 * i;