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 0B42C3858D20 for ; Mon, 22 Jan 2024 11:33:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0B42C3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0B42C3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705923236; cv=none; b=eLP8b/ti3H5Pcgz39g9MI9/Icw0fnRX6zDCS6Az9MMcgtUQdwJVoyhfbKMydxjK5GK6wQd+ptpAWjiy7CYtX1Kj3kIJznMRXIlHFrVGakdFiKEtSQ0+WHhmzp9wScLTHohXS0NQjMVYXYiAmW1zJyZ26iR1dyLiCxzg/Enu15fU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705923236; c=relaxed/simple; bh=oCD3mOQYukYYctVwFLTqWd61crVtqvOlLqmbE4gtt+4=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=O1B4KUHiRANJUz7p4d57qD4/kO+8P/+6nFF4z4uGhVbf47Q6vVXpRKJVck8sbEF+FKv7+HCnDsfWokxKUevmVFwuCjjLsEHX/38bEAuhhLMP3V3my2rNRPSxEdwNhBJOz7GmSS9Oq1cHpXX1UvM5XkKXQM6K5d2LgakZ+ERauOU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1705923234; 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=aiNI3pXUXFi/0Vq3sWD8uzZ+FyWu0KiPGtLQGPSNIhs=; b=NeOQFNOOcllVaQT7+CEUeN6gEvdtwjHQmwxrUM7UVPTErRi+h9TsRC7MRL17womts3qEdi hDyMB6DUuET6M5XZrfauj9GZibpvQh4REfYTkfGVAK+DZwmWbmrahb2RXf42tyhp79MoN0 RTfw+WPnon+ab+VyjzyKmI8gysEBUJg= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-171-jkgbltxrMYWS6hPkjdaV7A-1; Mon, 22 Jan 2024 06:33:52 -0500 X-MC-Unique: jkgbltxrMYWS6hPkjdaV7A-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AEAD02812940; Mon, 22 Jan 2024 11:33:52 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3B7F5492BC6; Mon, 22 Jan 2024 11:33:52 +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 40MBXnFn2621505 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 22 Jan 2024 12:33:50 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 40MBXnS52621504; Mon, 22 Jan 2024 12:33:49 +0100 Date: Mon, 22 Jan 2024 12:33:48 +0100 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] fold-const: Fold larger VIEW_CONVERT_EXPRs [PR113462] Message-ID: Reply-To: Jakub Jelinek References: <7E6ACD0B-8D1F-4653-9AFB-AF65E38B4FBA@suse.de> <92qqqs10-600r-p3pq-qn85-nrps7rrq938s@fhfr.qr> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 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=-4.3 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,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 List-Id: Hi! On Mon, Jan 22, 2024 at 11:56:11AM +0100, Richard Biener wrote: > > I guess the || total_bytes * BITS_PER_UNIT > HOST_BITS_PER_DOUBLE_INT > > conditions make no sense, all we care is whether it fits in the buffer > > or not. > > But then there is > > fold_view_convert_expr > > (and other spots) which use > > /* We support up to 1024-bit values (for GCN/RISC-V V128QImode). */ > > unsigned char buffer[128]; > > or something similar. > > Perhaps we could use XALLOCAVEC there instead (or use it only for the > > larger sizes and keep the static buffer for the common case). > > Well, yes. V_C_E folding could do this but then the native_encode_expr > API could also allow lazy allocation or so. native_encode_expr can't reallocate, it has to fill in whatever buffer it has been called with, it can be in the middle of something else etc. The following patch is what I meant, I think having some upper bound is desirable so that we don't spend too much time trying to VCE fold 2GB structures (after all, the APIs also use int for lengths) and similar and passed make check-gcc check-g++ -j32 -k GCC_TEST_RUN_EXPENSIVE=1 RUNTESTFLAGS="GCC_TEST_RUN_EXPENSIVE=1 dg.exp='*bitint* pr112673.c builtin-stdc-bit-*.c pr112566-2.c pr112511.c' dg-torture.exp=*bitint* dfp.exp=*bitint*" (my usual quick test for bitint related changes). Ok for trunk if it passes full bootstrap/regtest? 2024-01-22 Jakub Jelinek PR tree-optimization/113462 * fold-const.cc (native_interpret_int): Don't punt if total_bytes is larger than HOST_BITS_PER_DOUBLE_INT / BITS_PER_UNIT. (fold_view_convert_expr): Use XALLOCAVEC buffers for types with sizes between 129 and 8192 bytes. --- gcc/fold-const.cc.jj 2024-01-12 10:07:58.202851544 +0100 +++ gcc/fold-const.cc 2024-01-22 12:09:05.116253393 +0100 @@ -8773,8 +8773,7 @@ native_interpret_int (tree type, const u else total_bytes = GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (type)); - if (total_bytes > len - || total_bytes * BITS_PER_UNIT > HOST_BITS_PER_DOUBLE_INT) + if (total_bytes > len) return NULL_TREE; wide_int result = wi::from_buffer (ptr, total_bytes); @@ -9329,9 +9328,10 @@ fold_view_convert_vector_encoding (tree static tree fold_view_convert_expr (tree type, tree expr) { - /* We support up to 1024-bit values (for GCN/RISC-V V128QImode). */ unsigned char buffer[128]; + unsigned char *buf; int len; + HOST_WIDE_INT l; /* Check that the host and target are sane. */ if (CHAR_BIT != 8 || BITS_PER_UNIT != 8) @@ -9341,11 +9341,23 @@ fold_view_convert_expr (tree type, tree if (tree res = fold_view_convert_vector_encoding (type, expr)) return res; - len = native_encode_expr (expr, buffer, sizeof (buffer)); + l = int_size_in_bytes (type); + if (l > (int) sizeof (buffer) + && l <= WIDE_INT_MAX_PRECISION / BITS_PER_UNIT) + { + buf = XALLOCAVEC (unsigned char, l); + len = l; + } + else + { + buf = buffer; + len = sizeof (buffer); + } + len = native_encode_expr (expr, buf, len); if (len == 0) return NULL_TREE; - return native_interpret_expr (type, buffer, len); + return native_interpret_expr (type, buf, len); } /* Build an expression for the address of T. Folds away INDIRECT_REF Jakub