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 9C07F3858D35 for ; Tue, 10 Oct 2023 18:13:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C07F3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696961624; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=WdZGUt6L4VcZWBrb0Myba501Qs6P6YcxTvM/pW3kAT0=; b=iD0qr6L/2/tCwrmdc5O89qKtSu3TVTVYHY1loCfT28+iFvakTSJJs9zbRaGsy6SB8vTo3P AyvdYyOlk9MBdTwvdj+/z7N+7H2tjCRxCrsT8M6D6o9bI5noG6QxshbgPvhW2x2Joy334a 0Fd8eZHKlQHNxzkwSjy7+3119CnDb8g= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-182-E_MJaydgMCGJPaNtodYfKw-1; Tue, 10 Oct 2023 14:13:42 -0400 X-MC-Unique: E_MJaydgMCGJPaNtodYfKw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 44EFA185A78E; Tue, 10 Oct 2023 18:13:42 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.202]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DF2A840C6CA0; Tue, 10 Oct 2023 18:13:41 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 39AIDcIi137433 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 10 Oct 2023 20:13:39 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 39AIDbuB137410; Tue, 10 Oct 2023 20:13:37 +0200 Date: Tue, 10 Oct 2023 20:13:37 +0200 From: Jakub Jelinek To: Richard Biener , gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Subject: Re: [PATCH] wide-int: Allow up to 16320 bits wide_int and change widest_int precision to 32640 bits [PR102989] Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Oct 10, 2023 at 06:41:50PM +0100, Richard Sandiford wrote: > > On the wide_int side, I see > > 155291 576 > > (supposedly because of bound_wide_int, where we create wide_int_ref from > > the 576-bit precision bound_wide_int and then create 576-bit wide_int when > > using unary or binary operation on that). > > 576 bits seems quite a lot for a loop bound. We're enterning near-infinite > territory with 128 bits. :) But I don't want to rehash old discussions. > If we take this size for wide_int as given, then... We could go for 128 bits bounds_wide_int and redo the stats given that. Though maybe such tweaks can be done incrementally. > > So, perhaps we could get away with say WIDEST_INT_MAX_INL_ELTS of 5 or 6 > > instead of 9 but keep WIDE_INT_MAX_INL_ELTS at 9 (or whatever is computed > > from MAX_BITSIZE_MODE_ANY_INT?). Or keep it at 9 for both (i.e. without > > the third patch). > > ...I agree we might as well keep the widest_int size the same for > simplicity. It'd only be worth distinguishing them if we have positive > proof that it's worthwhile. > > So going with patches 1 + 2 sounds good to me, but I don't have a strong > preference. Ok. > > + if (prec > WIDE_INT_MAX_INL_PRECISION && !high) > > + prec = (op1len + op2len + 1) * HOST_BITS_PER_WIDE_INT; > > Changing the precision looked a bit dangerous at first, but I agree it > looks correct in context, in that nothing later on seems to require prec > to be the real precision of the number. But I wonder whether we should > instead do: > > if (!high) > prec = MIN ((op1len + op2len + 1) * HOST_BITS_PER_WIDE_INT, prec); Ok, will try that (and in other spots too). > so that the assumption gets a bit more testing. Same idea for the others. > I.e. in any case where we think it's safe to reduce a precision or > length for out-of-line buffers, I think we should try to do the same > for inline ones. > > I'm not sure off-hand why + 1 is safe here but + 2 is needed for the > write_val estimate. Might be worth a comment in one place or the other. As I wrote earlier, I'm not sure about the need for the + 1 above in prec computation, perhaps just if (!high) prec = MIN ((op1len + op2len + 1) * HOST_BITS_PER_WIDE_INT, prec); could work too (especially if the multiplication is always signed vs. signed or unsigned vs. unsigned). Even say HOST_WIDE_INT_MIN * HOST_WIDE_INT_MIN (i.e. op1len == op2len == 1) result of 0x40000000'000000000'00000000'00000000 (for smallest signed^2) or ~(unsigned HOST_WIDE_INT) 0 * ~(unsigned HOST_WIDE_INT) 0 (largest unsigned^2) of 0xffffffff'fffffffe'00000000'00000001 fits into prec 2; and for widest_int-like representation, 0xffffffff'ffffffffff wouldn't have op1len 1, but 2; but the + 1 on top of that is needed because of the way wi_pack then works. But guess will try to play with it some more tomorrow. > > @@ -2399,9 +2453,12 @@ from_int (int i) > > static void > > assert_deceq (const char *expected, const wide_int_ref &wi, signop sgn) > > { > > - char buf[WIDE_INT_PRINT_BUFFER_SIZE]; > > - print_dec (wi, buf, sgn); > > - ASSERT_STREQ (expected, buf); > > + char buf[WIDE_INT_PRINT_BUFFER_SIZE], *p = buf; > > + unsigned len = wi.get_len (); > > + if (UNLIKELY (len > WIDE_INT_MAX_INL_ELTS)) > > + p = XALLOCAVEC (char, len * HOST_BITS_PER_WIDE_INT / 4 + 4); > > Is this size enough for decimal? E.g. to go back to the 576-bit example, > 2^575 is O(10^173), but 576/4+4 == 148. generic_wide_ints with precision larger than HOST_BITS_PER_WIDE_INT and length larger than 1 are always printed hexadecimally, we don't have code to print it decimally (it wouldn't be terribly hard, we have divmod, but could be expensive). Though, I've always wondered why we at least for print_decs don't print negative values as -0xwhatever, rather than 0xsomethinglarge. Any change in this area could affect a lot of dumps though. Jakub