From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10783 invoked by alias); 16 Jun 2016 06:26:20 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 10710 invoked by uid 89); 16 Jun 2016 06:26:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=opportunity 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 16 Jun 2016 06:26:18 +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 4C8DB3710F1; Thu, 16 Jun 2016 06:26:17 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5G6QGh7002037; Thu, 16 Jun 2016 02:26:17 -0400 Subject: Re: [PATCH, vec-tails 05/10] Check if loop can be masked To: Richard Biener , Ilya Enkovich References: <20160519194208.GF40563@msticlxl57.ims.intel.com> Cc: GCC Patches From: Jeff Law Message-ID: <0c14e940-8f05-f8c9-718d-f66274a864b3@redhat.com> Date: Thu, 16 Jun 2016 06:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg01202.txt.bz2 On 06/15/2016 05:22 AM, Richard Biener wrote: > > You look at TREE_TYPE of LOOP_VINFO_NITERS (loop_vinfo) - I don't think > this is meaningful (if then only by accident). I think you should look at the > control IV itself, possibly it's value-range, to determine the smallest possible > type to use. Can we get an IV that's created after VRP? If so, then we have to be prepared for the case where there's no range information on the IV. At which point I think using type min/max of the IV is probably the right fallback. But I do think we should be looking at range info much more systematically. I can't see how TREE_TYPE of the NITERS makes sense either. > Finally we have a related missed optimization opportunity, namely avoiding > peeling for gaps if we mask the last load of the group (profitability depends > on the overhead of such masking of course as it would be done in the main > vectorized loop). I think that's a specific instance of a more general question -- what transformations can be avoided by masking and can we generate costs to select between those transformations and masking. Seems like a follow-up item rather than a requirement for this work to go forward to me. Jeff