From patchwork Mon Jan 22 11:33:48 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 190101 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2bc4:b0:101:a8e8:374 with SMTP id hx4csp2508444dyb; Mon, 22 Jan 2024 03:34:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IGzny3oAm2fbTjT6MRgHlnOlbYyTZZbA/TXIjFy9LFUwLDLOdqGLBRIBbxYmjmFbNvveZBr X-Received: by 2002:a05:6214:509e:b0:685:ce3f:5095 with SMTP id kk30-20020a056214509e00b00685ce3f5095mr4176528qvb.96.1705923280445; Mon, 22 Jan 2024 03:34:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705923280; cv=pass; d=google.com; s=arc-20160816; b=xmwrc12UY/JiUe3tEqfnnHPohbvumDlzAOAaH7Hoah6iCJM1flC1Jo/wbU0rTyvYDm NN+bCoCHxDaPQq0T28lm9etcsTrTcbaTOJVg8UH2ZKPCbtbsJ8/9uRDOtSRYrMFYJGWF Zb2lrlIqkstk5r2PHP53AddGV4zOJJ+/QuuhzkM3ZXo8tGJ52ffOYTsU/5/6xgf2i+NR 4pIcYfkW0Rmyxna1PwzMcsNO9d/Ogae38yZ5YzbnvnDLF5AnNAu3jZx231bzgF/DrN+W ic43diFuESDlCkuq6qt180jvMJ0/yau+ewJ3eAaJmhr8kZVdz2qnoeqqL+I2+fKPiljP 9eHw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:reply-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-disposition:in-reply-to :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:arc-filter:dmarc-filter:delivered-to; bh=aiNI3pXUXFi/0Vq3sWD8uzZ+FyWu0KiPGtLQGPSNIhs=; fh=FCjeRajqaQYHMkQtfIia8KT5yBac53mYOLLyJhYG/AY=; b=rB4jdbVDzOKZTzoug4/diRrdsEu5lD7x3kZ9cvZY2aYn/V6QOgDcOwR4JHL0JKg0f2 EK9WidzwcPqOuOVQyf6Lr3AZLl27R07bzfNXT8ld1h5l8M5gUnWy9h+YBjbd7ogRIpor V13CXzB6111OfXvnVEbF/wXLPqilQeZBM1QNyZkbxWaWYPRUEfWbvpdHKd4tU4EbEpM+ 71InU8KBdYM3K6eEy+p66qkaosPl7cWApj03rnTUDzqr+tcSxMX9ya798TB003mMmkrs 53+uxpweWZQqq8IgiXKNFlQpMKLVS+ku4sX2A023zcy7MZ9eqxaW2yBuBSECUogdxnGx VQfQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NeOQFNOO; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from server2.sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id o9-20020a0ce409000000b006818bb659c3si5438152qvl.103.2024.01.22.03.34.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 03:34:40 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NeOQFNOO; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 291F0385841A for ; Mon, 22 Jan 2024 11:34:40 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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: 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-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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788790210008410791 X-GMAIL-MSGID: 1788790210008410791 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. Jakub --- 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