From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62988 invoked by alias); 22 Jun 2016 17:42:56 -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 62978 invoked by uid 89); 22 Jun 2016 17:42:55 -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=realization 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; Wed, 22 Jun 2016 17:42:54 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 EF1F7C05B1ED; Wed, 22 Jun 2016 17:42:52 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-33.rdu2.redhat.com [10.10.116.33]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5MHgpnZ013311; Wed, 22 Jun 2016 13:42:52 -0400 Subject: Re: [PATCH, vec-tails 05/10] Check if loop can be masked To: Ilya Enkovich References: <20160519194208.GF40563@msticlxl57.ims.intel.com> <8c811442-df35-986a-d02d-b9c2669876d2@redhat.com> Cc: gcc-patches From: Jeff Law Message-ID: Date: Wed, 22 Jun 2016 17:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 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/msg01625.txt.bz2 On 06/22/2016 10:09 AM, Ilya Enkovich wrote: >> Given the common structure & duplication I can't help but wonder if a single >> function should be used for widening/narrowing. Ultimately can't you swap >> mask_elems/req_elems and always go narrower to wider (using a different >> optab for the two different cases)? > > I think we can't always go in narrower to wider direction because widening > uses two optabs wand also because the way insn_data is checked. OK. Thanks for considering. >> >> I'm guessing Richi's comment about what tree type you're looking at refers >> to this and similar instances. Doesn't this give you the type of the number >> of iterations rather than the type of the iteration variable itself? >> >> > > Since I build vector IV by myself and use to compare with NITERS I > feel it's safe to > use type of NITERS. Do you expect NITERS and IV types differ? Since you're comparing to NITERS, it sounds like you've got it right and that Richi and I have it wrong. It's less a question of whether or not we expect NITERS and IV to have different types, but more a realization that there's nothing that inherently says they have to be the same. THey probably are the same most of the time, but I don't think that's something we can or should necessarily depend on. >>> @@ -1791,6 +1870,20 @@ vectorizable_mask_load_store (gimple *stmt, >>> gimple_stmt_iterator *gsi, >>> && !useless_type_conversion_p (vectype, rhs_vectype))) >>> return false; >>> >>> + if (LOOP_VINFO_CAN_BE_MASKED (loop_vinfo)) >>> + { >>> + /* Check that mask conjuction is supported. */ >>> + optab tab; >>> + tab = optab_for_tree_code (BIT_AND_EXPR, vectype, optab_default); >>> + if (!tab || optab_handler (tab, TYPE_MODE (vectype)) == >>> CODE_FOR_nothing) >>> + { >>> + if (dump_enabled_p ()) >>> + dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, >>> + "cannot be masked: unsupported mask >>> operation\n"); >>> + LOOP_VINFO_CAN_BE_MASKED (loop_vinfo) = false; >>> + } >>> + } >> >> Should the optab querying be in optab-query.c? > > We always directly call optab_handler for simple operations. There are dozens > of such calls in vectorizer. OK. I would look favorably on a change to move those queries out into optabs-query as a separate patch. > > We don't embed masking capabilities into vectorizer. > > Actually we don't depend on masking capabilities so much. We have to mask > loads and stores and use can_mask_load_store for that which uses existing optab > query. We also require masking for reductions and use VEC_COND for that > (and use existing expand_vec_cond_expr_p). Other checks are to check if we > can build required masks. So we actually don't expose any new processor > masking capabilities to GIMPLE. I.e. all this works on targets with no > rich masking capabilities. E.g. we can mask loops for quite old SSE targets. OK. I think the key here is that load/store masking already exists and the others are either VEC_COND or checking if we can build the mask rather than can the operation be masked. THanks for clarifying. jeff