From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49217 invoked by alias); 16 Jun 2016 06:06:51 -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 49195 invoked by uid 89); 16 Jun 2016 06:06:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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:06:48 +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 C5C1180083; Thu, 16 Jun 2016 06:06:46 +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 u5G66ka7022481; Thu, 16 Jun 2016 02:06:46 -0400 Subject: Re: [PATCH, vec-tails 04/10] Add masking cost To: Ilya Enkovich , Richard Biener References: <20160519194036.GE40563@msticlxl57.ims.intel.com> Cc: GCC Patches From: Jeff Law Message-ID: Date: Thu, 16 Jun 2016 06:06: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/msg01200.txt.bz2 On 05/20/2016 05:32 AM, Ilya Enkovich wrote: > 2016-05-20 14:15 GMT+03:00 Richard Biener > : >> On Fri, May 20, 2016 at 11:44 AM, Ilya Enkovich >> wrote: >>> 2016-05-20 12:24 GMT+03:00 Richard Biener >>> : >>>> On Thu, May 19, 2016 at 9:40 PM, Ilya Enkovich >>>> wrote: >>>>> Hi, >>>>> >>>>> This patch extends vectorizer cost model to include masking >>>>> cost by adding new cost model locations and new target hook >>>>> to compute masking cost. >>>> >>>> Can you explain a bit why you add separate overall >>>> masking_prologue/body_cost rather than using the existing >>>> prologue/body cost for that? >>> >>> When I make a decision I need vector loop cost without masking >>> (what we currently have) and with masking (what I add). This >>> allows me to compute profitability for all options (scalar >>> epilogue, combined epilogue, masked epilogue) and choose one of >>> them. Using existing prologue/body cost would allow me compute >>> masking profitability with no fall back to scalar loop >>> profitability. >> >> Yes, but for this kind of purpose you could simply re-start >> separate costing via the init_cost hook? > > But that would require double scan through loop statements + double > profitability estimations. I compute masking cost during statements > analysis (see patch #05) in parallel with regular costs computations. > Note that masking costs is a cost of masking only. Thus cost of a > vector masked iteration is body cost + body masking cost. Unless there's some inherent reason not to, I prefer a single scan through the loop to compute the costs. Presumably the cost of the epilogue is not derived from the cost of the loop, so we ought to be able to build the costs via single scan. > >> >>>> I realize that the current vectorizer cost infrastructure is a >>>> big mess, but isn't it possible to achieve what you did with >>>> the current add_stmt_cost hook? (by inspecting stmt_info) >>> >>> Cost of a statement and cost of masking a statement are different >>> things. Two hooks called for the same statement return different >>> values. I can add vect_cost_for_stmt enum elements to cover >>> masking but I thought having stmt_masking_cost would me more >>> clear. >> >> I agree we need some kind of overloading and I'm not against a >> separate hook for this. On a related note what is "masking cost" >> here? I could imagine that masking doesn't unconditionally add a >> cost to a stmt but its execution cost may now depend on whether an >> element is masked or not. >> >> Does the hook return the cost of the masked stmt or the cost of >> masking the stmt only (so you need to do add_stmt_cost as well on >> the same stmt)? > > It returns the cost of masking the statement only. Thus if a > hardware has no penalty for executing masked instruction then return > value should be 0. Probably worth clarifying in the docs/code. Presumably if there's some kind of micro-architectural cost based on prior statements, their masking state, dependencies, etc we'd need a more robust API for computing this cost. But that's probably over-engineering at this point. Jeff