From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35569 invoked by alias); 5 Sep 2017 12:58:51 -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 23668 invoked by uid 89); 5 Sep 2017 12:58:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f54.google.com Received: from mail-wm0-f54.google.com (HELO mail-wm0-f54.google.com) (74.125.82.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Sep 2017 12:58:43 +0000 Received: by mail-wm0-f54.google.com with SMTP id f145so11043778wme.0 for ; Tue, 05 Sep 2017 05:58:43 -0700 (PDT) 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=Ud/GtVIZ/4Pbn9qd4G+i0HpZBdmL0XEbbuAKKA/dHSE=; b=mf1f/YqmN/IKjFZchuzckjmT6MEtdOXKqOvwW+V7iwZYccv0NN0uE2I1ifE/uHUtVD mjgfGClL2uFBG4ohOMpeg3TunaAH+rbny6CjjBBrtqTirlazhYeGrdOjddVg1PTB7SPx yEShUThDkbK4u/d4uZ0U70JyXhr070QZMMZrzLA/wopg+EQZKwFeRYsFz9mK7LnMp2Bq 0rgsOu/WhRZM7O616ub0IizZv+G9Ac77aIBHukIPobALLAj936unYRuxloeVJYqbDYnX uSyRWYO0KPUsdUWxl36MJO6h0+moZZCPKxhLL7D3fJb0SPCcptvvVBVi5nUyro375boS A+YA== X-Gm-Message-State: AHPjjUgbJOiq3cEnqq+5DkZrLZGBMYNv6BHd7/BmBbMhH0MtNGlzpICq gmwnzlGmJVIpEURbcY+5Rk0tKX89IA== X-Google-Smtp-Source: ADKCNb7dKj6jWNN27nvFZ6hixvulqYbUAiCEs5lrLNLnh7CGO7o2dEGQhy441gssOz4Z9eoI2IwRfEOoSXSGHPYHrV0= X-Received: by 10.80.136.24 with SMTP id b24mr3227446edb.246.1504616321479; Tue, 05 Sep 2017 05:58:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.180.205 with HTTP; Tue, 5 Sep 2017 05:58:40 -0700 (PDT) In-Reply-To: <87shg1z5oa.fsf@linaro.org> References: <87tw0iiu51.fsf@linaro.org> <878thuitk6.fsf@linaro.org> <87shg1z5oa.fsf@linaro.org> From: Richard Biener Date: Tue, 05 Sep 2017 12:58:00 -0000 Message-ID: Subject: Re: [5/9] Add mode_for_int_vector helper functions To: Richard Biener , GCC Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00266.txt.bz2 On Tue, Sep 5, 2017 at 2:33 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Mon, Sep 4, 2017 at 1:36 PM, Richard Sandiford >> wrote: >>> There are at least a few places that want to create an integer vector >>> with a specified element size and element count, or to create the >>> integer equivalent of an existing mode. This patch adds helpers >>> for doing that. >>> >>> The require ()s are all used in functions that go on to emit >>> instructions that use the result as a vector mode. >>> >>> 2017-09-04 Richard Sandiford >>> >>> gcc/ >>> * machmode.h (mode_for_int_vector): New function. >>> * stor-layout.c (mode_for_int_vector): Likewise. >>> * config/aarch64/aarch64.c (aarch64_emit_approx_sqrt): Use it. >>> * config/powerpcspe/powerpcspe.c (rs6000_do_expand_vec_perm): Likewise. >>> * config/rs6000/rs6000.c (rs6000_do_expand_vec_perm): Likewise. >>> * config/s390/s390.c (s390_expand_vec_compare_cc): Likewise. >>> (s390_expand_vcond): Likewise. >>> >>> Index: gcc/machmode.h >>> =================================================================== >>> --- gcc/machmode.h 2017-09-04 12:18:50.674859598 +0100 >>> +++ gcc/machmode.h 2017-09-04 12:18:53.153306182 +0100 >>> @@ -706,6 +706,21 @@ extern machine_mode bitwise_mode_for_mod >>> >>> extern machine_mode mode_for_vector (scalar_mode, unsigned); >>> >>> +extern opt_machine_mode mode_for_int_vector (unsigned int, unsigned int); >>> + >>> +/* Return the integer vector equivalent of MODE, if one exists. In other >>> + words, return the mode for an integer vector that has the same number >>> + of bits as MODE and the same number of elements as MODE, with the >>> + latter being 1 if MODE is scalar. The returned mode can be either >>> + an integer mode or a vector mode. */ >>> + >>> +inline opt_machine_mode >>> +mode_for_int_vector (machine_mode mode) >> >> So this is similar to int_mode_for_mode which means... >> >> int_vector_mode_for_vector_mode? > > I'd used that style of name originally, but didn't like it because > it gave the impression that the result would be a VECTOR_MODE_P. Oh, it isn't? Ah, yes, it can be an integer mode... > mode_for_int_vector was supposed to be consistent with mode_for_vector. > >>> +{ >> >> Nothing prevents use with non-vector MODE here, can we place an assert here? > > That was deliberate. I wanted it to work with scalars too, returning > a V1xx in that case. Ok. >>> + return mode_for_int_vector (GET_MODE_UNIT_BITSIZE (mode), >>> + GET_MODE_NUNITS (mode)); >>> +} >>> + >>> /* A class for iterating through possible bitfield modes. */ >>> class bit_field_mode_iterator >>> { >>> Index: gcc/stor-layout.c >>> =================================================================== >>> --- gcc/stor-layout.c 2017-09-04 12:18:50.675762071 +0100 >>> +++ gcc/stor-layout.c 2017-09-04 12:18:53.153306182 +0100 >>> @@ -517,6 +517,23 @@ mode_for_vector (scalar_mode innermode, >>> return mode; >>> } >>> >>> +/* Return the mode for a vector that has NUNITS integer elements of >>> + INT_BITS bits each, if such a mode exists. The mode can be either >>> + an integer mode or a vector mode. */ >>> + >>> +opt_machine_mode >>> +mode_for_int_vector (unsigned int int_bits, unsigned int nunits) >> >> That's more vector_int_mode_for_size (...), no? Similar to int_mode_for_size >> or mode_for_size. >> >> Ok with those renamings. I wonder if int_vector_mode_for_vector_mode >> is necessary -- is calling vector_int_mode_for_size >> (GET_MODE_UNIT_BITSIZE (mode), >> GET_MODE_NUNITS (mode)) too cumbersome? > > IMO yes :-) It's certainly longer than the equivalent int_mode_for_mode > expansion. I see. Patch is ok as-is then. Thanks, Richard. > Thanks, > Richard