From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93756 invoked by alias); 9 Mar 2017 08:02:42 -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 93739 invoked by uid 89); 9 Mar 2017 08:02:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*Ad:U*matz, H*f:sk:1489002, H*i:sk:1489002, material X-HELO: mail-ot0-f172.google.com Received: from mail-ot0-f172.google.com (HELO mail-ot0-f172.google.com) (74.125.82.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Mar 2017 08:02:39 +0000 Received: by mail-ot0-f172.google.com with SMTP id i1so51571184ota.3 for ; Thu, 09 Mar 2017 00:02:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZQG86/ouqDv+NydvT/tOZUp2CxteKCq2QvymyOoyWnw=; b=Eqb51wCDH3UVcFIYBQgA0rFhXJi9aO54vryPYp7nspIY+vi2MY4ilyHgPwK+PfXcKi 0QbJ3qgXjSCc9cHwWPn/4i/DPn4g3TwIXMq38SZ13Ar27HGqSvoE5vPK61g0mfSvvdBB 7WCsBoDotaL9WsZrFJXJYt6IiMLbKH/6dDKBA//r+88u1kQ9njRhuPpO2r7l7bX9wzU/ YTRiLjHu838gaqZhI+hg3TXwfNWZkj9PjsUinlCggDevzrEIfXxmtZ7p3m3jqpgUCML2 YXkmyV9r3iE/4tvZ5jV9pauxF7pRFdH7goYokOrmiCAhKsHT9z57vLo/QsfAQlK6JtnI DJwQ== X-Gm-Message-State: AMke39lTOr/xCOCsxy0J8s8zzWujCC0szSO8u8j8TlNvtL3LA4EJCP1t2jeSO7KsgBgEEN7PpwhsUCNkxYAcOQ== X-Received: by 10.157.82.171 with SMTP id f43mr5660282oth.191.1489046558747; Thu, 09 Mar 2017 00:02:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.25 with HTTP; Thu, 9 Mar 2017 00:02:38 -0800 (PST) In-Reply-To: <1489002090.22552.19.camel@caviumnetworks.com> References: <201703062237.v26MbW5e008866@sellcey-dt.caveonetworks.com> <1489002090.22552.19.camel@caviumnetworks.com> From: Richard Biener Date: Thu, 09 Mar 2017 08:02:00 -0000 Message-ID: Subject: Re: SPEC 456.hmmer vectorization question To: Steve Ellcey Cc: Michael Matz , GCC Development , Jeff Law Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00019.txt.bz2 On Wed, Mar 8, 2017 at 8:41 PM, Steve Ellcey wrote: > On Tue, 2017-03-07 at 14:45 +0100, Michael Matz wrote: >> Hi Steve, >> >> On Mon, 6 Mar 2017, Steve Ellcey wrote: >> >> > >> > I was looking at the spec 456.hmmer benchmark and this email string >> > from Jeff Law and Micheal Matz: >> > >> > https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01970.html >> > >> > and was wondering if anyone was looking at what more it would take >> > for GCC to vectorize the loop in P7Viterbi. > >> It takes what I wrote in there. There are two important things that need >> to happen to get the best performance (at least from an analysis I did in >> 2011, but nothing material should have changed since then): > > I guess I was hoping that some progress had been made since then, but > it sounds like it hasn't. > >> (1) loop distribution to make some memory streams vectorizable (and leave >> the others in non-vectorized form). >> (1a) loop splitting based on conditional (to remove the k >> (2) a predictive commoning (or loop carried store reuse) on the dc[] >> stream >> >> None of these is valid if the loop streams can't be disambiguated, and as >> this is C only adding explicit restrict qualifiers would give you that, or >> runtime disambiguation, like ICC is doing, that's part (0). > > So it sounds like the loop would have to be split up using runtime > disambiguation before we could do any of the optimizations. Would that > check and split be something that could or should be done using the > graphite framework or would it be a seperate pass done before the > graphite phase is called? I am not sure how one would determine what > loops would be worth splitting and which ones would not during such a > phase. 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. Richard. > Steve Ellcey > sellcey@cavium.com