From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85551 invoked by alias); 12 Dec 2017 15:57:01 -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 85524 invoked by uid 89); 12 Dec 2017 15:57:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3687 X-HELO: mail-pf0-f174.google.com Received: from mail-pf0-f174.google.com (HELO mail-pf0-f174.google.com) (209.85.192.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Dec 2017 15:56:59 +0000 Received: by mail-pf0-f174.google.com with SMTP id l24so14509166pfj.6 for ; Tue, 12 Dec 2017 07:56:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=spK2ClZja623B4Wojw/q4VfPLACywiutGODkz1Xc/Zk=; b=Lans6lYAEqlyphAKPNHoXYtN31DG6/QZ+0ma92Gf+Zr9VDHNdYbeUKoWbfTdthTTJT mZPghFVGrQglMD3JQ4dsUv0YfC9QHQscSNtwQHMn+RFr7oWdTXKARkqoubmP/eryyy9k xQeJCrTBeX5xeRONNQ8RvQaXsDdf/kmfi6qKKpbpqcbOND9JZBgZc+/y5hHdpC4j4iYz goFnBMej9P5ZfwmuG5ms+nyAehCl20vUqKHUM33YuOHw1pb6Ij0F9hmqW3TQ/QR1Y2x2 Mf+G6OvEGSUnGjuvkxjZDqTsmAOLpCLVvC3sJF1M8XBh6Kw3wMhT+2WS1RSN8ec/vmz7 LYxQ== X-Gm-Message-State: AKGB3mKy/muBfkFZUVneL0N024OWorcdacWRf8ibAnUsXn8K9UURUBsL 48Q8h6FuyuIt0ngSmC+thGmjr9Lss/c= X-Google-Smtp-Source: ACJfBotxZR7c/hgpFHKO2HNNkn2B5HMA+tBz1tOHPWmxlpZ589SMJIBexHUqDkg7vlQVbKOzlFMpsQ== X-Received: by 10.159.246.7 with SMTP id b7mr2606922pls.81.1513094217238; Tue, 12 Dec 2017 07:56:57 -0800 (PST) Received: from localhost (i121-117-160-225.s30.a048.ap.plala.or.jp. [121.117.160.225]) by smtp.gmail.com with ESMTPSA id b9sm35383245pfl.108.2017.12.12.07.56.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 12 Dec 2017 07:56:55 -0800 (PST) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,GCC Patches , richard.sandiford@linaro.org Cc: GCC Patches Subject: Re: [00/13] Make VEC_PERM_EXPR work for variable-length vectors References: <87indfmrgt.fsf@linaro.org> <87k1xsq7wq.fsf@linaro.org> Date: Tue, 12 Dec 2017 15:57:00 -0000 In-Reply-To: (Richard Biener's message of "Tue, 12 Dec 2017 16:38:18 +0100") Message-ID: <87a7yoq6rf.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-12/txt/msg00743.txt.bz2 Richard Biener writes: > On Tue, Dec 12, 2017 at 4:32 PM, Richard Sandiford > wrote: >> Richard Biener writes: >>> On Sun, Dec 10, 2017 at 12:06 AM, Richard Sandiford >>> wrote: >>>> This series is a replacement for: >>>> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00747.html >>>> based on the feedback that using VEC_PERM_EXPR would be better. >>>> >>>> The changes are: >>>> >>>> (1) Remove the restriction that the selector elements have to have the >>>> same width as the data elements, but only for constant selectors. >>>> This lets through the cases we need without also allowing >>>> potentially-expensive ops. Adding support for the variable >>>> case can be done later if it seems useful, but it's not trivial. >>>> >>>> (2) Encode the integer form of constant selectors (vec_perm_indices) >>>> in the same way as the new VECTOR_CST encoding, so that it can >>>> cope with variable-length vectors. >>>> >>>> (3) Remove the vec_perm_const optab and reuse the target hook to emit >>>> code. This avoids the need to create a CONST_VECTOR for the wide >>>> selectors, and hence the need to have a corresponding wide vector >>>> mode (which the target wouldn't otherwise need or support). >>> >>> Hmm. Makes sense I suppose. >>> >>>> (4) When handling the variable vec_perm optab, check that modes can store >>>> all element indices before using them. >>>> >>>> (5) Unconditionally use ssizetype selector elements in permutes created >>>> by the vectoriser. >>> >>> Why specifically _signed_ sizetype? That sounds like an odd choice. >>> But I'll >>> eventually see when looking at the patch. >> >> Sorry, should have said. The choice doesn't matter for vector lengths >> that are a power of 2, > > which are the only ones we support anyway? Yeah, for fixed-length at the tree level. The variable-length support allows (2^N)*X vectors for non-power-of-2 X though, and we support non-power-of-2 fixed-length vectors in RTL (e.g. V12QI). >> but for others, using a signed selector means that >> -1 always selects the last input element, whereas for unsigned selectors, >> the element selected by -1 would depend on the selector precision. (And the >> use of sizetype precision is pretty arbitrary.) > > hmm, so you are saying that vec_perm is equal > to vec_perm tree.def defines VEC_PERM_EXPR via > > N = length(mask) > foreach i in N: > M = mask[i] % (2*N) > A = M < N ? v0[M] : v1[M-N] > > which doesn't reflect this behavior. Does this behavior persist for variable > vector permutations? __builtin_shuffle is defined to wrap though: The elements of the input vectors are numbered in memory ordering of @var{vec0} beginning at 0 and @var{vec1} beginning at @var{N}. The elements of @var{mask} are considered modulo @var{N} in the single-operand case and modulo @math{2*@var{N}} in the two-operand case. I think we need to preserve that for VEC_PERM_EXPR, otherwise we'd need to introduce the masking operation when lowering __builtin_shuffle to VEC_PERM_EXPR. >>> Does that mean we have a VNDImode vector unconditionally for the >>> permute even though a vector matching the width of the data members >>> would work? >> >> A VECTOR_CST of N DIs, yeah. It only becomes a VNDI at the rtl level >> if we're selecting 64-bit data elements. > > And on GIMPLE? Do we have a vector type with ssizetype elements > unconditionally? For autovectorised permutes, yes. Other permutes we keep the existing types. Thanks, Richard