From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23019 invoked by alias); 24 Oct 2017 11:18:50 -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 22921 invoked by uid 89); 24 Oct 2017 11:18:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=noisy, Hx-languages-length:3399 X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Oct 2017 11:18:47 +0000 Received: by mail-wm0-f48.google.com with SMTP id b189so14904121wmd.4 for ; Tue, 24 Oct 2017 04:18:47 -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=IxtJJWFA5kjsmDmEVZI8M9+pHRdqZjQ8KouvTUv4Cvs=; b=Bg40CT62DA9x3DXWFsOlcGcMlmEbqPI8RVWwtVXLaJrZN5Qzog6Cv2eNlGS44AwBhW sR0HYuQDSC8VM281Jn5oSBVIQNpmWT8BXuOngpQPBOIOYhF+b96403N6oesBO8sN7Mc0 ICxpTbk9Om+P5XzkbHPsGX3pF/+o1Cp9f0fHRK7QSUeAJmpgD1NemONinAZEdizQh4ZA kBclAnE5ZnS+f+LMbX+AEy0O/7fApLbEB0x7jimj0FGmuUmJEp8sJyttaI5EmgqOJMBe mQD4NalgplbRbX7uwGrt9VfNbOVw4kKaiuD8LxI+xloJVfh5dVQ7QQyZrfNrBcrv+d2i 6PWQ== X-Gm-Message-State: AMCzsaX5dF53ok0DATgD4mp2jD9fFzn3gPmioFzmJlves1NSm2/kn4Vl jR3Ame4LfCClFyxQhnn7/4pCrTQ1Mqs= X-Google-Smtp-Source: ABhQp+ShVBfiKz3iy8b3Y9SZxQrHiHdgv0qqBJwH8kD+rXWUON06IURUJPLVinqUIolc/ug6HsJXqg== X-Received: by 10.28.126.146 with SMTP id z140mr2425569wmc.126.1508843925247; Tue, 24 Oct 2017 04:18:45 -0700 (PDT) Received: from localhost (92.40.249.209.threembb.co.uk. [92.40.249.209]) by smtp.gmail.com with ESMTPSA id e8sm64605wmc.46.2017.10.24.04.18.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Oct 2017 04:18:44 -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> <87she8q3yk.fsf@linaro.org> Date: Tue, 24 Oct 2017 11:20:00 -0000 In-Reply-To: (Richard Biener's message of "Tue, 24 Oct 2017 11:58:33 +0200") Message-ID: <87k1zkpze5.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/msg01681.txt.bz2 Richard Biener writes: > On Tue, Oct 24, 2017 at 11:40 AM, Richard Sandiford > wrote: >> 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). > > Going to be interesting (bitrot) times then? I wonder if it makes sense > to initially define it to 2 globally and only change it to 1 later? Well, the target-independent code doesn't have the implicit conversion from poly_int<1, C> to C, so it can't e.g. do: poly_int64 x = ...; HOST_WIDE_INT y = x; even when NUM_POLY_INT_COEFFS==1. Only target-specific code (identified by IN_TARGET_CODE) can do that. So to target-independent code it doesn't really matter what NUM_POLY_INT_COEFFS is. Even if we bumped it to 2, the extra coefficient would always be zero. FWIW, the poly_int tests in [001/nnn] cover N == 1, 2 and (as far as supported) 3 for all targets, so that part isn't sensitive to NUM_POLY_INT_COEFFS. > Do you have any numbers on the effect of poly-int on compile-times? > Esp. for example on stage2 build times when stage1 is -O0 -g "optimized"? I've just tried that for an x86_64 -j24 build and got: real: +7% user: +8.6% I don't know how noisy the results are though. It's compile-time neutral in terms of running a gcc built with --enable-checking=release, within a margin of about [-0.1%, 0.1%]. Thanks, Richard