From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57126 invoked by alias); 20 May 2016 11:32:30 -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 57099 invoked by uid 89); 20 May 2016 11:32:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=enkovich.gnu@gmail.com, enkovichgnugmailcom, Hx-languages-length:2708 X-HELO: mail-vk0-f53.google.com Received: from mail-vk0-f53.google.com (HELO mail-vk0-f53.google.com) (209.85.213.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 20 May 2016 11:32:25 +0000 Received: by mail-vk0-f53.google.com with SMTP id z184so139667152vkg.0 for ; Fri, 20 May 2016 04:32:25 -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:date :message-id:subject:from:to:cc; bh=n3UgHIRWNZAVTVIhrKO7af6+lClq7iVQW11nq9VC+HM=; b=mMrYKbWCez1HNYLsA8Mgjt8FzZY9SmjO1nJSDl6NCgbOlwNGl5oNN3DGx7VnTacI1H H+TEzyzo8DBqbfpZD6X/qMyxN7NSzlM4mWDhng6DL63VvYqZqa1e9xHWps5w/Nhsn5Ms AofZGGHSYl1J9IuiMP90aGXla5QMIG6a1GLNyEKIoQwINtrosAvQLFEJJ/aGQLxUImr2 Lsjpr7yEA+6ubRp37h4Z7xBc6GsXrVjEhwWxtillbrk1JconnZgpFm+wCPUPBsgQ5oZt fOyC7BDVt1IhcVCKmxXcTkSNavGoUvBsCZC/ZF7z0IBSh75wgGOINKS06WGDWbGV49kK 6bIA== X-Gm-Message-State: AOPr4FXOGgTLCM+KoSNsYNXUMLWimGolPdWqqoBhqv6JKyKKexX9hnBSKCnD6eLqekU9yDpEv7HAGOMqquiTYg== MIME-Version: 1.0 X-Received: by 10.31.80.7 with SMTP id e7mr1377499vkb.124.1463743943602; Fri, 20 May 2016 04:32:23 -0700 (PDT) Received: by 10.176.3.208 with HTTP; Fri, 20 May 2016 04:32:23 -0700 (PDT) In-Reply-To: References: <20160519194036.GE40563@msticlxl57.ims.intel.com> Date: Fri, 20 May 2016 11:32:00 -0000 Message-ID: Subject: Re: [PATCH, vec-tails 04/10] Add masking cost From: Ilya Enkovich To: Richard Biener Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg01629.txt.bz2 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. > >>> 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. Thanks, Ilya > > Thanks, > Richard. > >> Thanks, >> Ilya >> >>> >>> Richard. >>> >>>> Thanks, >>>> Ilya