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 F38CF3858416 for ; Tue, 29 Aug 2023 14:46:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F38CF3858416 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=1693320376; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=iVP+uzyt2PjnKoLiIZNM4IEq2J2AceAxGLE3gOcEHvU=; b=VpeINU7ovJB4eyzagBET9BXEP3S1JEfBjzNUw7mHm1Zv10VOGbjHnQVXhQPaDPVrkpZ0yr f3G1osXXRcIBG+XEUh/qBSz4XZLBolNgUyeXXPO+nOjza7FWxuuPZGmwac1sISJrwlfd8S U3ekDux3zgWpGr9nKsx9Z/9Qde9TR8Y= 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-100-SsJy7v8GMWq0PZH80-QAtA-1; Tue, 29 Aug 2023 10:46:15 -0400 X-MC-Unique: SsJy7v8GMWq0PZH80-QAtA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DFB9F185A7AE; Tue, 29 Aug 2023 14:46:14 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9A7AD2026D68; Tue, 29 Aug 2023 14:46:14 +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 37TEkCJp3866104 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 29 Aug 2023 16:46:12 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 37TEkCNm3866103; Tue, 29 Aug 2023 16:46:12 +0200 Date: Tue, 29 Aug 2023 16:46:12 +0200 From: Jakub Jelinek To: Richard Biener Cc: Richard Sandiford , gcc-patches@gcc.gnu.org Subject: Re: [RFC] > WIDE_INT_MAX_PREC support in wide-int Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 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_H4,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, Aug 29, 2023 at 09:49:59AM +0000, Richard Biener wrote: > The simplest way would probably to keep widest_int at > WIDE_INT_MAX_PRECISION like we have now and assert that this is > enough at ::to_widest time (we probably do already). And then > declare uses with more precision need to use GMP. > > Not sure if that's not also a viable way for wide_int - we're > only losing optimization here, no? No. In lots of places it is essential (constant evaluation), in other places very much desirable optimization even or especially on _BitInt (e.g. value range optimizations, ccp, ...) and then sure, spots where just punting on larger _BitInt for optimization is something we can live with (and yet other spots which only happen after the lowering and so will never see that at all). I think if we go with allowing _BitInt (N) for N >= WIDE_INT_MAX_PRECISION, the most important thing is we want to slow down the compiler as little as possible for the common case, no _BitInt at all or _BitInt smaller than that, and furthermore from maintainance POV, we want most of the code to work as is. Adding assertion that precision is < WIDE_INT_MAX_PRECISION on widest_int construction from wide_int/INTEGER_CST etc. wouldn't achieve those goals. Grepping outside of wide-int.{cc,h} for widest_int, I see around 450 matches, sure, that doesn't mean 450 places where we'd need to add some guard to punt for the larger _BitInt (if it is possible to punt at all), but I'm sure it would be more than hundred of places. And having similarly say 50% of those 100-200 spots have a fallback using gmp would be also a maintainance nightmare, because those spots for larger precisions would be much less tested than normal code. Sure, we can add some guards in some places and the niter stuff could very well be one of them, or simply also use there wide_int with carefully chosen precision, say WIDE_INT_MAX_PRECISION if _BitInt isn't involved or at most 128 bits, and otherwise something wider. But I'm worried of the maintainance nightmare etc. if we have to touch hundreds of places and figure out how to punt or what else to do in each of those spots. Compared to this, I see only 15 hits for widest2_int, in 2 places, arith_overflowed_p and operator_mult::wi_fold, that is something that could very well be done either always using appropriate wider precision wide_int, or even do it twice, once for < WIDE_INT_MAX_PRECISION input precision and another time wider. Jakub