From patchwork Fri Dec 8 07:37:04 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 175654 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp5298633vqy; Thu, 7 Dec 2023 23:37:34 -0800 (PST) X-Google-Smtp-Source: AGHT+IEeFmko6BMrhGRO2yI3LzRMW6nknHgbsRpapP/pMqefVEaZQ16/AZJUiSjCgKnvblV81WSA X-Received: by 2002:a05:620a:1a1d:b0:77e:fde7:697d with SMTP id bk29-20020a05620a1a1d00b0077efde7697dmr2757006qkb.99.1702021054037; Thu, 07 Dec 2023 23:37:34 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1702021054; cv=pass; d=google.com; s=arc-20160816; b=hPbj8OX+eMXzPkNL5eCXLy6/j/A1TKgsUcCn6E/Dy5VhOEAyP1eUBcYinB7bJLRcP3 Dspvb+yM506/1eURvsDj1MuKUg4nTRxbcKPF+QzNNQflsy2XztCbmGKb6G662t3iRczP P0gJlb04iHDySSTuZYOioycRYSWZueAQvqA5MbxpwP5PmHh6kJYOgAxdxt/e0XaLrz6e 7wodgLSEyFa3Gu/D75Wp3/x8YBza/JYkqE/5v06Mx38Ya1baGVfBl64ec0//ecvMkXAA 2gqYSfQQdoRzd0UjwPMRa7nwhvOP99MUbCe3j3HhDSuYfi6QVHL3mYxyirA5NOxuiHlh WLgQ== 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=mHxYA6YRDxLhkJA/aj5TW45Rd0+7IW4N3OYo6QTwzjc=; fh=1eSk23nwesQJIzDgYGQ70Zwi44eJ5HnGJs8f4OTh0UY=; b=K0JAk1SlynzRmdlbUtXxN5Rzk7iYgyVnxvM9t1QMhwStouSkacXX97cfKxQmSAmA9G avF4h0a+vcQrJBMvMmbiZ45PWFP6bC9+2BCQdxnCqcT7HfeB8M9HHmN3io4hp8QlIgFr mTwwMZLv1zY2gK0xh0/qUj/z8XPvhctloj60azJCtLrVtGOspW+l/ZgANuNlTZhoq7IG cLbBxKkXpKT/OdfreDLVF5oq+Vjh/235C3c+VNkBEegsQgNXoFXlN2tbnuZI1LOBSwtu Xl9ESYwnsKb767EuZJEOqThOOffS5Vy/QUUt3SOARjAmJnMEe0SK6niLlEkPQt6KSsko O3zg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=A+iDxp8F; 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 k3-20020ae9f103000000b0077da9bb9868si1394858qkg.446.2023.12.07.23.37.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Dec 2023 23:37:34 -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=A+iDxp8F; 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 C9223385702B for ; Fri, 8 Dec 2023 07:37:33 +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 8753A3858C60 for ; Fri, 8 Dec 2023 07:37:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8753A3858C60 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 8753A3858C60 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=1702021031; cv=none; b=gp0egoUggGiSuPztzGYjReDUQijP2K0axFZGMGlQJavA3GJ+NDDHk+hpkmMDxiTfR/OaMm7x1Evf8IOYUJ/DttqLdTx4LvPllTftZnZ8xTdvQj1kVezX7enjX/S0zoiRcnnzZ7shKjye7lfQpvmlK0JXgJnpmpLn9JLDww/iQj4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702021031; c=relaxed/simple; bh=Hl3Df42bkU9yDamOHbXnZg+608buzf0YJliT+Jp9KXk=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=wGcSfYhkHvfrq7K0L5K7pL6nDeVn9nC/l2S5ALCEBQxQnQgpX7wgxsWL1vac5i5kODp9hHeChqJVz3CcPnbB47ecZZTZ56vvit6TkeBvJWSD5fIhSvgkXlE2hhMSwsnjllhtAd0KkHVbCZ2Ljt6oxFIsN8tuRqYNqOq5yLw9gmc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702021030; 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=mHxYA6YRDxLhkJA/aj5TW45Rd0+7IW4N3OYo6QTwzjc=; b=A+iDxp8FCHqSN27V3qDJjcVdpS4GkdeBTySn4X3tS363wu6x4CAFNX/5VpTYh7kyCvjf13 Z6LXKMLYbcFMy0AK5gxsKZAbushVg66M9NkAGX+CHxAttxH+bbSZrgpnXubDaupeEnxHDk 8AQoT9op7dJFa7vd0l3vctSh8co3QJ0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-641-OKyvx7BWN_i7XQ31RlmICQ-1; Fri, 08 Dec 2023 02:37:08 -0500 X-MC-Unique: OKyvx7BWN_i7XQ31RlmICQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 EF71D868900; Fri, 8 Dec 2023 07:37:07 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.157]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AFDE8C185A0; Fri, 8 Dec 2023 07:37:07 +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 3B87b5oG2911143 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 8 Dec 2023 08:37:05 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 3B87b4OQ2911142; Fri, 8 Dec 2023 08:37:04 +0100 Date: Fri, 8 Dec 2023 08:37:04 +0100 From: Jakub Jelinek To: Richard Biener , Vladimir Makarov Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] haifa-sched: Avoid overflows in extend_h_i_d [PR112411] Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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, 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: 1784698429156155251 X-GMAIL-MSGID: 1784698429156155251 On Thu, Dec 07, 2023 at 11:54:01AM +0100, Jakub Jelinek wrote: > On Thu, Dec 07, 2023 at 09:36:23AM +0100, Jakub Jelinek wrote: > > Without the dg-skip-if I got on 64-bit host: > > cc1: out of memory allocating 571230784744 bytes after a total of 2772992 bytes > > I've looked at this and the problem is in haifa-sched.cc: > 9047 h_i_d.safe_grow_cleared (3 * get_max_uid () / 2, true); > get_max_uid () is 0x4000024d with the --param min-nondebug-insn-uid=0x40000000 > and so 3 * get_max_uid () / 2 actually overflows to -536870028 but as vec.h > then treats the value as unsigned, it attempts to allocate > 0xe0000374U * 152UL bytes, i.e. those 532GB. If the above is fixed to do > 3U * get_max_uid () / 2 instead, it will get slightly better and will only > need 0x60000373U * 152UL bytes, i.e. 228GB. Here it is in a patch form. For the other changes, it would be more work and the question is if it would be beneficial for average compilation, if the uids aren't sparse enough, it would waste more memory (8-bytes per uid for the pointer in the array plus the 152 byte allocation, probably even rounded up for next bucket size unless we use say pool allocator). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2023-12-08 Jakub Jelinek PR middle-end/112411 * haifa-sched.cc (extend_h_i_d): Use 3U instead of 3 in 3 * get_max_uid () / 2 calculation. Jakub --- gcc/haifa-sched.cc.jj 2023-08-08 15:55:06.705161670 +0200 +++ gcc/haifa-sched.cc 2023-12-07 11:57:17.869611646 +0100 @@ -9044,7 +9044,7 @@ extend_h_i_d (void) if (reserve > 0 && ! h_i_d.space (reserve)) { - h_i_d.safe_grow_cleared (3 * get_max_uid () / 2, true); + h_i_d.safe_grow_cleared (3U * get_max_uid () / 2, true); sched_extend_target (); } }