From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25379 invoked by alias); 9 Mar 2017 08:12:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 24010 invoked by uid 89); 9 Mar 2017 08:12:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=H*Ad:U*matz, H*f:sk:1489002, H*i:sk:dSEfbaq, H*i:1cbhv 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; Thu, 09 Mar 2017 08:12:52 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B44F97E9D3; Thu, 9 Mar 2017 08:12:51 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-76.ams2.redhat.com [10.36.117.76]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v298CnBI002371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Mar 2017 03:12:51 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v298CkPB022469; Thu, 9 Mar 2017 09:12:46 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v298ChRU021305; Thu, 9 Mar 2017 09:12:43 +0100 Date: Thu, 09 Mar 2017 08:12:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: Steve Ellcey , Michael Matz , GCC Development , Jeff Law Subject: Re: SPEC 456.hmmer vectorization question Message-ID: <20170309081243.GE22703@tucnak> Reply-To: Jakub Jelinek References: <201703062237.v26MbW5e008866@sellcey-dt.caveonetworks.com> <1489002090.22552.19.camel@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00020.txt.bz2 On Thu, Mar 09, 2017 at 09:02:38AM +0100, Richard Biener wrote: > It would need to be done before graphite, and yes, the question is when > to do this (given the non-trival text size and runtime cost). One option is > to do sth similar like we do with IFN_LOOP_VECTORIZED, that is, after > followup transforms decide whether the specialized version received any > important optimization. Another option is to add value profile counters > for aliasing and only do this with FDO when we know at runtime there > is no aliasing. It doesn't have to be either/or. If we have FDO, we can do it unconditionally if we have gathered into that there is likely no aliasing, and optimize the other loop (for the case of aliasing) for size. If we don't have FDO, we could do the IFN_LOOP_VERSIONED way. For IFN_LOOP_VERSIONED, if we check all aliasing cases we could then either use the OpenMP/Cilk/ivdep pragma loop properties (loop->safelen etc.), or even have something stronger (that would say that there aren't any inter-iteration memory dependencies). Jakub