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 883D13858D28 for ; Mon, 4 Dec 2023 19:38:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 883D13858D28 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 883D13858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701718691; cv=none; b=tLzt4kGWcj+QFwE781VkK3UIHyzA56s4DgnqnNSfaAcfR64wD52ufbspqYPrYwv4wVokhWmP7lsi2SBawz8lwEwIDxUd8v/Dk83DnmEeBiwSvgLVaRiB4T/ot4kqYWYH8oVVEzjvRlPehPFHcAyorbnFzTXXVw+5Vz8Qw7phOIk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701718691; c=relaxed/simple; bh=G1RYfZ77p6ydDQwTEbjwWjJqv86don+W4PL4GvgLHNM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=FMjk9ZnsEAsSZLfWVbD/dmEmEn7cNHMN2l+6rXjkmfgZ396Et2V9+6QKJg8C/neTPis3mWA/EHS6HMRfXaEEzueumDL/MPcP1xzVgfidwnSnuG2vYghyJc0YTU/uGkm38X0r8HA7BT7vnR9aANbOR1rQVftIbxQ36oEb0anDsxE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701718681; 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=H6P4PImBJ3w6jF7khUicLOsSarFcnI3pBaoIen4cv0U=; b=X70UTh39hxHFUSOMfx0MLemNhnOddebFd7HyU00LYGvkI8BwMtooKx8ZfVkDY9+jNLewpK 3FOJFhAYdH8w3J8TsNHoegKhty0S0YRIjvhi9mfgPl8TPEVQVLm0KSX8WxyJg77JOmtJ6v pBZhj/M2AbREck07Ra6eO3uo5EASotY= 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-503-eeCmwDOsPB2qX8rwtscOuA-1; Mon, 04 Dec 2023 14:34:24 -0500 X-MC-Unique: eeCmwDOsPB2qX8rwtscOuA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (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 A547C29AA3BB; Mon, 4 Dec 2023 19:34:23 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.157]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 321122166B26; Mon, 4 Dec 2023 19:34:23 +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 3B4JYJd42173037 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 4 Dec 2023 20:34:20 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 3B4JYIM62173036; Mon, 4 Dec 2023 20:34:18 +0100 Date: Mon, 4 Dec 2023 20:34:18 +0100 From: Jakub Jelinek To: Eric Botcazou , Segher Boessenkool , Jeff Law , gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Subject: Re: [PATCH] Maintain a validity flag for REG_UNUSED notes [PR112760] (was Re: [PATCH] pro_and_epilogue: Call df_note_add_problem () if SHRINK_WRAPPING_ENABLED [PR112760]) 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.6 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.6 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,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: On Mon, Dec 04, 2023 at 05:30:45PM +0000, Richard Sandiford wrote: > > I don't think it's worth adding the note problem to shrink-wrapping > > just for the regcprop code. If we're prepared to take that compile-time > > hit, we might as well run a proper (fast) DCE. > > Here's a patch that tries to do that. Boostrapped & regression tested > on aarch64-linux-gnu. Also tested on x86_64-linux-gnu for the testcase. > (I'll run full x86_64-linux-gnu testing overnight.) > > OK to install if that passes? Not an elegant fix, but it's probably > too much to hope for one of those. Isn't this way too conservative though, basically limiting single_set to ~ 15 out of the ~ 65 RTL passes (sure, it will still DTRT for non-PARALLEL or just PARALLEL with clobbers/uses)? Do we know about passes other than postreload which may invalidate REG_UNUSED notes while not purging them altogether? Given what postreload does, I bet cse/gcse might too. If we add a RTL checking verification of the notes, we could know immediately what other passes invalidate it. So, couldn't we just set such flag at the end of such passes (or only if they actually remove any redundant insns and thus potentially invalidate them, perhaps during doing so)? And on the x86 side, the question from the PR still stands, why is vzeroupper pass placed exactly after reload and not postreload which cleans stuff up after reload. Jakub