From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1262 invoked by alias); 14 Dec 2017 10:37:08 -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 1248 invoked by uid 89); 14 Dec 2017 10:37:07 -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_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f43.google.com Received: from mail-wm0-f43.google.com (HELO mail-wm0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Dec 2017 10:37:00 +0000 Received: by mail-wm0-f43.google.com with SMTP id y82so25615159wmg.1 for ; Thu, 14 Dec 2017 02:37:00 -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=I5pYOZkcXkCZ0yTsdijGsB0J1N9DsY/OtPF7dInOqxQ=; b=UBPXNP8Ut3dJr0KZXx3bUR3v2tFl+nifxwsJ6Gx1SPSQgZOp4slcu257gMqQdYOyrp 6qygk0MYUvJzipBV9t3rzuPq07zDw92joWHkR4HZkK3NczvY5hJmkBTXmIqewLRp/mdN FwVYQagd4cZJL60qhnkCgTDcAdnR2Pj7Q0WAgOK+yAB5Of4BBRoicF6pfzUzsVv+hEdm hTA5gcIeowyI7RvLTjGQYbFzfRgZxDz0K7CYQJTI+DYM3kvjjY9vCFROXB+1F3zaWZiU EVeA3e5XbIQO7JgTDOc7bGY4Po82v7vkVf0jiz58Os1B/QZuXVZporrt5NtxFrAqQr/N 2rqg== X-Gm-Message-State: AKGB3mLrB+9ZFpSHXtjl2A4fO2EM2NhtkKAA8HYraXRGXqmnIrdltZdC g9Ksshg+uf8MvJqYnCfEbpejtQVNDLkkLHMVLbQ= X-Google-Smtp-Source: ACJfBovl31IAICsxDKQ/rmo6ryzgru9XyDDE4WWvcYCM2je4tUO5Rb6GEcY991gagg0AzOyN8VSOfORDnvlCkITXHCM= X-Received: by 10.80.137.106 with SMTP id f39mr3525472edf.148.1513247818650; Thu, 14 Dec 2017 02:36:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.167.196 with HTTP; Thu, 14 Dec 2017 02:36:58 -0800 (PST) In-Reply-To: <87efo0q780.fsf@linaro.org> References: <87indfmrgt.fsf@linaro.org> <87lgiblc9q.fsf@linaro.org> <87efo0q780.fsf@linaro.org> From: Richard Biener Date: Thu, 14 Dec 2017 10:37:00 -0000 Message-ID: Subject: Re: [07/13] Make vec_perm_indices use new vector encoding To: Richard Biener , GCC Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00885.txt.bz2 On Tue, Dec 12, 2017 at 4:46 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Sun, Dec 10, 2017 at 12:20 AM, Richard Sandiford >> wrote: >>> This patch changes vec_perm_indices from a plain vec<> to a class >>> that stores a canonicalised permutation, using the same encoding >>> as for VECTOR_CSTs. This means that vec_perm_indices now carries >>> information about the number of vectors being permuted (currently >>> always 1 or 2) and the number of elements in each input vector. >> >> Before I dive into the C++ details can you explain why it needs this >> info and how it encodes it for variable-length vectors? To interleave >> two vectors you need sth like { 0, N, 1, N+1, ... }, I'm not sure we >> can directly encode N here, can we? extract even/odd should just >> work as { 0, 2, 4, 6, ...} without knowledge of whether we permute >> one or two vectors (the one vector case just has two times the same >> vector) or how many elements each of the vectors (or the result) has. > > One of the later patches switches the element types to HOST_WIDE_INT, > so that we can represent all ssizetypes. Then there's a poly_int > patch (not yet posted) to make that poly_int64, so that we can > represent the N even for variable-length vectors. > > The class needs to know the number of elements because that affects > the canonical representation. E.g. extract even on fixed-length > vectors with both inputs the same should be { 0, 2, 4, ..., 0, 2, 4 ... }, > which we can't encode as a simple series. Interleave low with both > inputs the same should be { 0, 0, 1, 1, ... } for both fixed-length and > variable-length vectors. Huh? extract even is { 0, 2, 4, 6, 8 ... } indexes in the selection vector are referencing concat'ed input vectors. So yes, for two same vectors that's effectively { 0, 2, 4, ..., 0, 2, 4, ... } but I don't see why that should be the canonical form? > Also, operator[] is supposed to return an in-range selector even if > the selector element is only implicitly encoded. So we need to know > the number of input elements there. > > Separating the number of input elements into the number of inputs > and the number of elements per input isn't really necessary, but made > it easier to provide routines for testing whether all selected > elements come from a particular input, and for rotating the selector > by a whole number of inputs. > > Thanks, > Richard