From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55194 invoked by alias); 12 Dec 2017 15:38:25 -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 55038 invoked by uid 89); 12 Dec 2017 15:38:24 -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,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f41.google.com Received: from mail-wm0-f41.google.com (HELO mail-wm0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Dec 2017 15:38:21 +0000 Received: by mail-wm0-f41.google.com with SMTP id b76so21206082wmg.1 for ; Tue, 12 Dec 2017 07:38:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=uQGpnIJmC0TZZ8sQFbTWlMWgJEKIdBEJwTaj6Xubdbs=; b=m1FORw+/b2MNffHDq6sY47E/ghQGvEnsn2ZvcLmrUcSQwRpowue7VIa79HQr41ItNG OfNVNj6/XA1KnjviT86PdCwnTttcAgk6hYIDPnzYuutbuNzjrpaqepPsqwPR7QtdzmWh CAQXEGnir5W/d8UEE4TL008XkxjPmIREEfA0h1FtTP5OtTi8FfKUbJgXlzr3kG0HlEJX MsIip5hBp2WKaLAFUY4b+uPK8kP00mf407e/ITo4UwHmq+lMjjqsaazs9+226h/eoJaC N5tWvaKft6pPUtCTA0C+m10Wazrg/gmQoAv8YVQFGF/yzlt3pGgNqlSEBwZpgGht3SdU LKSQ== X-Gm-Message-State: AKGB3mIq1YXY3u1nSKflyMiRNcSoNv1v9JYW/w4ZIDQzGf0CENLY44dD jA9BIQ53rW9eEyIPN8ZqlODuSZpabdzxhG+wu9BblQmQ X-Google-Smtp-Source: ACJfBoulOkTBfoBz+Q7ou1iht2Ld2awSkdXapZK7Xprun1P3ViUfs+eCYYl41qGHRst1rP+wqWe2SjK4+8xiP0vgEys= X-Received: by 10.80.144.168 with SMTP id c37mr3451907eda.182.1513093099318; Tue, 12 Dec 2017 07:38:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.167.196 with HTTP; Tue, 12 Dec 2017 07:38:18 -0800 (PST) In-Reply-To: <87k1xsq7wq.fsf@linaro.org> References: <87indfmrgt.fsf@linaro.org> <87k1xsq7wq.fsf@linaro.org> From: Richard Biener Date: Tue, 12 Dec 2017 15:38:00 -0000 Message-ID: Subject: Re: [00/13] Make VEC_PERM_EXPR work for variable-length vectors To: Richard Biener , GCC Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00741.txt.bz2 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? > 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 >> 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? >> What happens if the target doesn't have vec_perm_const but vec_perm to >> handle all constant permutes? > > We'll try to represent the selector as VN?I, where ? matches the width > of the data, but only after checking that that doesn't change the > selector values. So for current targets we'll use vec_perm for constant > permutes as before, but we wouldn't for 2-input V256QI interleaves. I see. Richard. > Thanks, > Richard