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 288373858D28 for ; Fri, 1 Jul 2022 17:43:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 288373858D28 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-480-i-aLh48DPWOT51mZuXdZeQ-1; Fri, 01 Jul 2022 13:43:38 -0400 X-MC-Unique: i-aLh48DPWOT51mZuXdZeQ-1 Received: by mail-oa1-f71.google.com with SMTP id 586e51a60fabf-10851e269eeso1854215fac.1 for ; Fri, 01 Jul 2022 10:43:38 -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=glNbQOew5qEyvNdEnnx3NvkEkWgDUps5BUdvyAhohX0=; b=ZlaXb96SIhl4ThYelLSRCn+XoPYleqF62yCj0cZX/ZF99jm5Au7s0kmduWkmLWo2LZ WtsSmFFRt2ULX1rLb4SrZru9W4V+2tS5j4jEBMyf4bWU/usrli10DNL1B5vOrjtEvNSu nOsgwN9jvY5n34ae1QafWrlIrNJmzReucn1J3i0h3GfD0xNad9cAWLLxqvHhIB8BrCCX JSKKSrm2z2V1yInWBONqybA16m2vT4S9z3y9jAImwROQfJOnb9fBuHx53xuMyTDgP02L pMuvUw6m147nOTaP6Jw3alrgrcpTnmPkbI0tVkS5NZCizNpLQb2lDeNnHHLbgtphus/h xDFw== X-Gm-Message-State: AJIora9v0fnN3qlNvA7N72GyxhBQ7CM4S/OgjUgvqjYmTwCN+VyQUe4g XmoVXsdeOz/U9wyPT80rlitUGaslBMWps0QS+quJ8i34CBR//g7ITZsRaUH1gA4WmjbvoQYhcCY xDuSN1Iqksf9WoZGyOGV3Vy/y3UihE+mYxw== X-Received: by 2002:a05:6808:1a26:b0:335:63ee:7c32 with SMTP id bk38-20020a0568081a2600b0033563ee7c32mr10462787oib.36.1656697417992; Fri, 01 Jul 2022 10:43:37 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s+jxamMhNM5XeOP06RBqjJNFZDnM7W4wduHPKn7Gl4sHpF+wT2bcqmybo8wl1UWCOwSLrCRjl2Sy1VB22lpBI= X-Received: by 2002:a05:6808:1a26:b0:335:63ee:7c32 with SMTP id bk38-20020a0568081a2600b0033563ee7c32mr10462776oib.36.1656697417773; Fri, 01 Jul 2022 10:43:37 -0700 (PDT) MIME-Version: 1.0 References: <20220629092157.230287-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Fri, 1 Jul 2022 19:43:28 +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 X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 17:43:43 -0000 On Fri, Jul 1, 2022, 18:58 Jakub Jelinek wrote: > On Fri, Jul 01, 2022 at 06:47:48PM +0200, Aldy Hernandez wrote: > > > 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 :). > > So, you still use N = 3 but can sometimes store say 255 wide_ints in there? > In that case, m_len[N] provides lengths just for the first 3, no? > You can still say N=255 and things continue to work as they do now, since m_len[] is still statically determined. The only difference is that before, the size of the structure would be 2+1+255+sizeof(int) whereas now it would be 1 more because of the byte I'm using for num_elements. The only time this would be an issue would be for say N=253 because the size of everything except the ints is currently 256 (2+1+253), which is 64 bit aligned, whereas with my patch it would be 257 which takes an additional word. This is all theoretical because there are no users of trailing wide ints greater than 3. I guess what I'm really doing is changing the semantics of trailing_wide_ints to trailing_wide_ints and what used to be the number of elements is determined at run time....but the default is MAX so everything continues to work the same for the current users. Does that make sense? Aldy > Anyway, you really want feedback from Richard Sandiford IMHO... > > Jakub > >