From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56425 invoked by alias); 22 Jun 2016 15:03:16 -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 56330 invoked by uid 89); 22 Jun 2016 15:03:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=opportunity X-HELO: mail-vk0-f54.google.com Received: from mail-vk0-f54.google.com (HELO mail-vk0-f54.google.com) (209.85.213.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 22 Jun 2016 15:03:13 +0000 Received: by mail-vk0-f54.google.com with SMTP id d185so65687104vkg.0 for ; Wed, 22 Jun 2016 08:03:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FrgBM/JA11QyU6mK3Z5k4SqflmPf0I0j5gH+713zUAI=; b=ClnjJEyqbNdmcMQfbiwvEZv3sUoStmQ6OZSSqH3rp55eYIKc1eUsgHvLjLjSHVl42a wjXiHujG0R4/TwFQw5XGUk74l+LaUoaX+9W3CtO6zcnv+gzb0WsMtVK2edRorWPo57W/ w7kq2W7F5BEJG1XasDkTQBgN508PUOGioTq57tEJia+DiPsq4Ado2bcXkUGBJ8yfSRQ7 gBVfpxfuzhuwfMJzrJ3OXU4O3Qx4P+jpJat9QrTWqt+Z9gS0F+VvMSv0fXdhtOJ/RvCs wJ4NSEXfwU1di8a5+oTL0R6zxNBdMjbpW/27YpLz9qZIn5EUU+NmA2EnsIL7jlEpGZeu Utgw== X-Gm-Message-State: ALyK8tLLb7JpqtiEBfZehTrcjL4SB3k2sCGCGjBFE8Z7gYSHgIjRUDPYE+LWp/o033hMRowvOsONLCGR1bbp2A== X-Received: by 10.176.6.74 with SMTP id f68mr10110134uaf.137.1466607791518; Wed, 22 Jun 2016 08:03:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.5.201 with HTTP; Wed, 22 Jun 2016 08:03:11 -0700 (PDT) In-Reply-To: <0c14e940-8f05-f8c9-718d-f66274a864b3@redhat.com> References: <20160519194208.GF40563@msticlxl57.ims.intel.com> <0c14e940-8f05-f8c9-718d-f66274a864b3@redhat.com> From: Ilya Enkovich Date: Wed, 22 Jun 2016 15:03:00 -0000 Message-ID: Subject: Re: [PATCH, vec-tails 05/10] Check if loop can be masked To: Jeff Law Cc: Richard Biener , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg01612.txt.bz2 2016-06-16 9:26 GMT+03:00 Jeff Law : > 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. I need to build a vector {niters, ..., niters} and compare to it. Why doesn't it make sense to choose the same type for IV? I agree that choosing a smaller type may be beneficial. Shouldn't I look at nb_iterations_upper_bound then to check if NITERS can be casted to a smaller type? Thanks, Ilya > >> 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