From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48399 invoked by alias); 24 Oct 2017 09:40:15 -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 48390 invoked by uid 89); 24 Oct 2017 09:40:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f181.google.com Received: from mail-wr0-f181.google.com (HELO mail-wr0-f181.google.com) (209.85.128.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Oct 2017 09:40:08 +0000 Received: by mail-wr0-f181.google.com with SMTP id o44so19989571wrf.11 for ; Tue, 24 Oct 2017 02:40:08 -0700 (PDT) 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=Xge0yyMTJgoEcpniKKLabrIKZvyOse9XMFoZKp1JA8o=; b=gYMKz4A9PWtQnriuCKL+/SrgyAlgU5x7mMU/R6aDIgddsId0jixuOEQpHx6dMf4DSf HH4mg8ZmRnk2HZjMpPCu84nG2OD6HKHw2zhZ7xqT+betRyDTYVwfESkg7tkn9eX6/5nF ZxkoA+uWtnLB4T7auAjlijS2CyHSenVgZbpRf2+XUfLbjVQEiZKe2XroeW5pPa4oJ21L gN6q7K4p/noPo9KL+jmInktOwXMw+WXU29KRr0hL0kkFXFsBk1093Z97TGo56Sby0zP0 D2L302MuULbU20dJ+c96/8qtTNw0GqpRKFKrvC3sGa0eWZqhY0aGSqQgX1VrjiiVne/q HKaQ== X-Gm-Message-State: AMCzsaXu+TyAM0WEYbkovuh8k6mgc+56cgtyEL2M9MMbF1b358xb0mXB m8skQlWht+/8PlPC6nUI18KN0yQa6V8= X-Google-Smtp-Source: ABhQp+SntOK2TszsCDkXTFoEzbuk+alvrKnjtGAoaJjdqvhnsno8Mgebrss2lqaVS5fqBzjPC5Cd+w== X-Received: by 10.223.174.142 with SMTP id y14mr12285902wrc.222.1508838006379; Tue, 24 Oct 2017 02:40:06 -0700 (PDT) Received: from localhost (92.40.249.209.threembb.co.uk. [92.40.249.209]) by smtp.gmail.com with ESMTPSA id t189sm744071wmf.43.2017.10.24.02.40.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Oct 2017 02:40:05 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,GCC Patches , richard.sandiford@linaro.org Cc: GCC Patches Subject: Re: [103/nnn] poly_int: TYPE_VECTOR_SUBPARTS References: <871sltvm7r.fsf@linaro.org> <87fua9damy.fsf@linaro.org> Date: Tue, 24 Oct 2017 09:40:00 -0000 In-Reply-To: (Richard Biener's message of "Tue, 24 Oct 2017 10:49:47 +0200") Message-ID: <87she8q3yk.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-10/txt/msg01660.txt.bz2 Richard Biener writes: > On Mon, Oct 23, 2017 at 7:41 PM, Richard Sandiford > wrote: >> This patch changes TYPE_VECTOR_SUBPARTS to a poly_uint64. The value is >> encoded in the 10-bit precision field and was previously always stored >> as a simple log2 value. The challenge was to use this 10 bits to >> encode the number of elements in variable-length vectors, so that >> we didn't need to increase the size of the tree. >> >> In practice the number of vector elements should always have the form >> N + N * X (where X is the runtime value), and as for constant-length >> vectors, N must be a power of 2 (even though X itself might not be). >> The patch therefore uses the low bit to select between constant-length >> and variable-length and uses the upper 9 bits to encode log2(N). >> Targets without variable-length vectors continue to use the old scheme. >> >> A new valid_vector_subparts_p function tests whether a given number >> of elements can be encoded. This is false for the vector modes that >> represent an LD3 or ST3 vector triple (which we want to treat as arrays >> of vectors rather than single vectors). >> >> Most of the patch is mechanical; previous patches handled the changes >> that weren't entirely straightforward. > > One comment, w/o actually reviewing may/must stuff (will comment on that > elsewhere). > > You split 10 bits into 9 and 1, wouldn't it be more efficient to use the > lower 8 bits for the log2 value of N and either of the two remaining bits > for the flag? That way the 8 bits for the shift amount can be eventually > accessed in a more efficient way. > > Guess you'd need to compare code-generation of the TYPE_VECTOR_SUBPARTS > accessor on aarch64 / x86_64. Ah, yeah. I'll give that a go. > Am I correct that NUM_POLY_INT_COEFFS is 1 for targets that do not > have variable length vector modes? Right. 1 is the default and only AArch64 defines it to anything else (2). Thanks, Richard