From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 9B4EA385782C for ; Fri, 1 Jul 2022 16:48:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9B4EA385782C Received: from mail-oa1-f71.google.com (mail-oa1-f71.google.com [209.85.160.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-384-g2Yqttb-NM66pnP6E_fJ1A-1; Fri, 01 Jul 2022 12:48:00 -0400 X-MC-Unique: g2Yqttb-NM66pnP6E_fJ1A-1 Received: by mail-oa1-f71.google.com with SMTP id 586e51a60fabf-108be115284so1767451fac.23 for ; Fri, 01 Jul 2022 09:48:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kID6sDI9XtJpvBSKLW9k51CCX2/r9h4zzrFE8+LAe0A=; b=d/IJp4v7gTjAievnsxqDqHCmab68LOptDBfhdap4CVjZiR2FUfZjAY3XrJrGrJNV6a tOW7mi4vQEsZN9XEUsFBItlqGNbkU9kWnxG4rqyB9bgmjAHRJaKdWh4vLvQa0zNKhORR Wd2zibbSVGnUqku52eTPWVU6X18IaM5eLwOHgJLzITyRz4ElpyxuZcSfya5ggpdYkBUT QOZCxAQufmq9wHm9E/x+XQnSAR+mlWzOJZQ4xOW/sGKbZ8Qlx29YIX8PJYuFJ5K+/mzb bxGkcfv/bHFleT1XrxmediyWm4wMFOOE7q1Q8kS7pa/UUxtfibZrA6OV2fIB/QhhBzV9 iRHQ== X-Gm-Message-State: AJIora+GJZoi/IcGUwmv/3exU4rTvUFy+W6/SC8j/kZ0KiLdis5kIO8Q LZZBuZF5FmF18VgBCuvuws/jmkShCi3PmBrcfhmEu/1J3HSV7TXkpwd5ZKFTKKBAszxDVve7w14 ga3YrO5IqdkuKztJWZu1WNi972FCfFVWbmw== X-Received: by 2002:a05:6830:48:b0:616:ada0:5378 with SMTP id d8-20020a056830004800b00616ada05378mr6977296otp.276.1656694079636; Fri, 01 Jul 2022 09:47:59 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sjbAwPRp++ESqpJhfKNnrddRCG1Bm4LJ3ncm2KJPz50fkNeCObLtnDVE/CSK9EkvIT6gole23OuASr+8DVHQY= X-Received: by 2002:a05:6830:48:b0:616:ada0:5378 with SMTP id d8-20020a056830004800b00616ada05378mr6977290otp.276.1656694079405; Fri, 01 Jul 2022 09:47:59 -0700 (PDT) MIME-Version: 1.0 References: <20220629092157.230287-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Fri, 1 Jul 2022 18:47:48 +0200 Message-ID: Subject: Re: [RFC] trailing_wide_ints with runtime variable lengths To: Jakub Jelinek Cc: GCC patches , Andrew MacLeod , Richard Sandiford X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2022 16:48:04 -0000 On Fri, Jul 1, 2022 at 4:58 PM Jakub Jelinek wrote: > > On Fri, Jul 01, 2022 at 04:12:55PM +0200, Aldy Hernandez wrote: > > > --- a/gcc/wide-int.h > > > +++ b/gcc/wide-int.h > > > @@ -1373,10 +1373,13 @@ namespace wi > > > : public int_traits {}; > > > } > > > > > > -/* An array of N wide_int-like objects that can be put at the end of > > > - a variable-sized structure. Use extra_size to calculate how many > > > - bytes beyond the sizeof need to be allocated. Use set_precision > > > - to initialize the structure. */ > > > +/* A variable-lengthed array of wide_int-like objects that can be put > > > + at the end of a variable-sized structure. The number of objects is > > > + at most N and can be set at runtime by using set_precision(). > > > + > > > + Use extra_size to calculate how many bytes beyond the > > > + sizeof need to be allocated. Use set_precision to initialize the > > > + structure. */ > > > template > > > struct GTY((user)) trailing_wide_ints > > > { > > > @@ -1387,6 +1390,9 @@ private: > > > /* The shared maximum length of each number. */ > > > unsigned char m_max_len; > > > > > > + /* The number of elements. */ > > > + unsigned char m_num_elements; > > IMNSHO you certainly don't want to change like this existing > trailing_wide_ints, you don't want to grow unnecessarily existing > trailing_wide_ints users (e.g. const_poly_int_def). That's precisely what I avoided...touching existing trailing_wide_ints users. As I explained, there is no cost to either const_poly_int_def or range_info_def (though I'm about to nuke the latter). There is some padding that is currently used by m_len[N], and I just took a byte out to represent the run-time length. That would affect trailing_wide_int users that have N > 4, but none are. The use in const_poly_int_def uses 2 (and range_info_def uses 3): #define NUM_POLY_INT_COEFFS 2 struct GTY((variable_size)) const_poly_int_def { trailing_wide_ints coeffs; }; > > My brief understanding of wide-int.h is that in some cases stuff like this > is implied from template parameters or exact class instantiation and in > other cases it is present explicitly and class inheritence is used to hide > that stuff nicely. Yeah, it took me a while to decipher it, but I did read it :). > > So, you are looking for something like trailing_wide_ints but where that > N is actually a runtime value? Then e.g. the > struct {unsigned char len;} m_len[N]; > member can't work properly either, because it isn't constant size. What my patch does is store the run-time length in the aforementioned byte, while defaulting to N/MAX. There is no size difference (or code changes) for existing users. With my change, set_precision() and extra_size() now take a runtime parameter, but it defaults to N and is inlined, so there is no penalty for existing users. I benchmarked to make sure :). I could hack up a variable_length_wide_int for what I want, but I'd end up duplicating a lot of the trailing_wide_int_storage, etc. Another option would be to stream out the HOST_WIDE_INTs in the tree_int_cst and reconstruct things myself, but that smells of reinventing the wheel. Is there another way of allocating an n-bit wide-int at run-time? I'm happy to entertain other alternatives... Aldy