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.129.124]) by sourceware.org (Postfix) with ESMTPS id AB4B63858C54 for ; Fri, 1 Jul 2022 20:40:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AB4B63858C54 Received: from mail-ot1-f69.google.com (mail-ot1-f69.google.com [209.85.210.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-327-wal5f00aNHW2muDa4NUrAA-1; Fri, 01 Jul 2022 16:40:27 -0400 X-MC-Unique: wal5f00aNHW2muDa4NUrAA-1 Received: by mail-ot1-f69.google.com with SMTP id f34-20020a9d03a5000000b0060c46a7869aso1672163otf.2 for ; Fri, 01 Jul 2022 13:40:27 -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=+ESc05v8wNngbq2AnpocQy4g+2O6dQpczldX/8FMjh4=; b=b7znpb4TeKev/lsHYhmR9BIBVpFG5+aVTbdQC9TeCPVDjTQJk2bbr2nVi0gLGwjcYu ynRD02gpt+O+7KCVgYDV8OAYjIwDZ5rbLrqp+SXBlZQCbBYjVAtsoDk598HFYTti7ZPb P+ZHsQiA6K+Fqlscjep+688kGDjbaCIJ01EBcWoqG5qyyFl6l8MYDvmK9irxLUPTBoq8 tXq5FMFOPb7yrrewXluC6Pn1KkZq/xDDx6gJXNzg7qjnWySMK7C5SWjU6oyfctY4b0VH M05FKO+b40H59deDdf5PaaiHt8MqyddZjBxshdAffGw630UJYMRhlF+RQsaoZnwgv4jb lJSg== X-Gm-Message-State: AJIora/uOKFLUWssVrMR8mniIvGheIFxhbbj3Yp1yNtvbeoNLy/tmc8x m3oEb4gMqvT7Y4EYZdzRkuM9reDNhvFkVRA7/T+0y/GUMY3cRd7QIuu9re4lgD96YEMvGyakgE2 4DOBuIL74xR9Us9v1XbWOEGzm+F+o/kyFBg== X-Received: by 2002:a05:6870:c38e:b0:ed:f230:1494 with SMTP id g14-20020a056870c38e00b000edf2301494mr10778976oao.36.1656708026595; Fri, 01 Jul 2022 13:40:26 -0700 (PDT) X-Google-Smtp-Source: AGRyM1swKl24/FjgevultWfDksIhrEG1SPcrADk7p9XZKMys6zuUOpXaa8xwUcOLgdRmtSQohn1mP6pAKvPgOZEGHoM= X-Received: by 2002:a05:6870:c38e:b0:ed:f230:1494 with SMTP id g14-20020a056870c38e00b000edf2301494mr10778963oao.36.1656708026411; Fri, 01 Jul 2022 13:40:26 -0700 (PDT) MIME-Version: 1.0 References: <20220629092157.230287-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Fri, 1 Jul 2022 22:40:15 +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.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, 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 20:40:29 -0000 BTW, I don't know if it got lost in all my patches, but we already have an irange allocator that given an irange, returns a chunk of memory holding a clone of that irange squished into its minimum representable pairs (see vrange_allocator and friends). So we won't ever be storing 255 or something equally absurd like I had proposed years ago :). We'll be storing the smallest representable range inside a trailing_wide_int. Aldy On Fri, Jul 1, 2022 at 10:31 PM Aldy Hernandez wrote: > > On Fri, Jul 1, 2022 at 8:53 PM Jakub Jelinek wrote: > > > > On Fri, Jul 01, 2022 at 07:43:28PM +0200, Aldy Hernandez wrote: > > > 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. > > > > So, what N do you want to use for SSA_NAME_RANGE_INFO? > > N=255 wouldn't be very space efficient especially if the common case is a > > single range or two. > > For such cases making e.g. m_len not an embedded array, but pointer to > > somewhere after the HOST_WIDE_INT array in the same allocation would be > > better. > > As I mentioned in my original post, 12. This means that I'm taking > the 4 bytes that are left over from the current padding plus 8 > (64-bits). My trailing wide int structure for SSA_NAME_RANGE_INFO > will be one word larger than what is currently there. But we'll be > able to store up to 5 pairs plus one for the nonzero bits plus one for > future development (5*2 + 1 + 1 = 12), all without going over the 64 > bit alignment. > > This is a theoretical max, in reality as I mentioned, 99% of ranges > calculated in infinite precision by the ranger fit into 3-4 pairs. > > Aldy