From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id ED9F93858D33 for ; Sat, 2 Dec 2023 19:30:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ED9F93858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org ED9F93858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::530 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701545427; cv=none; b=WbxmtUPbz4x0Jl10/saGrYBXNixtkdr5hQeoa20r6MfWsf4B8SV1RQibysMRFRCiyyDcOp1qlG3Abu7yenKP3K1th5A2cY2nLCTIOJdUaNSht0mWWsvn1XYZd8UU9X/Y/ugWdHPbWpAJZxB7N00yB8u2rsuxRCLtqDzZpZukNXo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701545427; c=relaxed/simple; bh=X8f4vquBLzTuIp/f7A4f7uf7+mUfMSsnMwvR67eTqLc=; h=DKIM-Signature:From:Mime-Version:Subject:Date:Message-Id:To; b=UvC0+CpXxYdEf1boCbFWqkyqIDaijQNa4HbwCnWhjXHoY5G9LANB3X7RLfMH4nAD0cqsBzydZ2Fl258Hh9lZP7Mux93rQ1ncVtr/o6szH6G9rixIXAfuRlVh+JbUGx2o0Zi+G5FIjanY1cuk4ClZdT3fWdx8EqdJB4Qys0bmukY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-548ce39b101so4025212a12.2 for ; Sat, 02 Dec 2023 11:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701545422; x=1702150222; darn=gcc.gnu.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=57oEfUxH1+Da7RReWAjwKcxCCSAlvEYz5/jCWfzQkd4=; b=cSjP0BWJYuo4u4XIjLuL1bfetndmtyp5piz92gIsj17pmsUQANbtrXTpNFx9FW423c 0OJPVJebfRD5pt9rIZZUMLhzt3g6TGyTY9u5A/5PhwA+na8NO99wvTVPm9vBjdo27feh dEqsRlxL9QRSsARjPyw7nzOhtb8/ZDgkjQPU3tu1Yg70kfPIS2tyYrWnZBK6WB1mKru6 qUbKZ2W8VP031+Zri5Am3FSDSMC1pH0nAiVJqkjmhedVogIDnDOpLbqOa2XJ8meQUYlm 6i9OAi/9RxY9DSaG5U7Yr78gsSUTC0l3LCkUGQfCqV9w2F3nDc7+guSEjk/xGIl6PTuZ HtuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701545422; x=1702150222; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=57oEfUxH1+Da7RReWAjwKcxCCSAlvEYz5/jCWfzQkd4=; b=ArVmvv6tw1U4HIxDseRtgYu8IDgFIQSNCzRxuaUoib5HDE7vs9K5MX5zDuOyfeodAK wrAB2qXKKGIkLex0K90pKnaeO7p/N5zjqn9n3XI8Hlpjj8Yn0jBZis/UCO5PoPJYFexl SwTZJFZ/ZqaoYudhq84I+cAaZ2bcVMXWXFVOauHeEYL7IzBjNZW/YIv0GPEqRIBDIcVe IHChFn0Hn0MNmESsLwnx+ZKk7QM19kdHD6ZNAXPB0cKL44Q0grDHuM/xZp9C9jnpfZY5 OfG+CRHcJ4/ydreNiOm7Qj4b40Olmli3tcwFJ8a21Y5yAzlaUmaD+oUbMhhZLriKmy2X OI9g== X-Gm-Message-State: AOJu0YyY7E3TahnuOfI7Se5eUL5tIVrhL3Ht+OGog9rpCrKTh/VFUD+g NYKV589ofWnp753LRWzDVFA= X-Google-Smtp-Source: AGHT+IF3Sabe6icY5ugMTwr3aOIVNjuYSk/caABmMtrSjRVqJJxAq5WpSB2Ar1S7rJxzSLz7MdMwFA== X-Received: by 2002:a50:8a85:0:b0:54c:4837:7d3c with SMTP id j5-20020a508a85000000b0054c48377d3cmr1314503edj.123.1701545422241; Sat, 02 Dec 2023 11:30:22 -0800 (PST) Received: from smtpclient.apple (dynamic-095-117-056-079.95.117.pool.telefonica.de. [95.117.56.79]) by smtp.gmail.com with ESMTPSA id i22-20020a05640242d600b0054c72a6a07csm1248236edc.84.2023.12.02.11.30.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Dec 2023 11:30:21 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] pro_and_epilogue: Call df_note_add_problem () if SHRINK_WRAPPING_ENABLED [PR112760] Date: Sat, 2 Dec 2023 20:30:10 +0100 Message-Id: References: Cc: Eric Botcazou , Jakub Jelinek , Segher Boessenkool , Jeff Law , gcc-patches@gcc.gnu.org In-Reply-To: To: Richard Sandiford X-Mailer: iPhone Mail (21B101) X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: > Am 02.12.2023 um 14:15 schrieb Richard Sandiford : >=20 > =EF=BB=BFEric Botcazou writes: >>> So sorry to be awkward, but I don't think this is the way to go. I thin= k >>> we'll just end up playing whack-a-mole and adding df_note_add_problem to= >>> lots of passes. >>=20 >> We have doing that for the past 15 years though, so what has changed? >=20 > Off-hand, I couldn't remember a case where we'd done this specifically > for false-positive REG_UNUSED notes. (There probably were cases though.) >=20 >>> (FTR, I'm not saying passes have to avoid false negatives, just false >>> positives. If a pass updates an instruction with a REG_UNUSED note, >>> and the pass is no longer sure whether the register is unused or not, >>> the pass can just delete the note.) >>=20 >> Reintroducing the manual management of such notes would be a step backwar= d. >=20 > I think false-positive REG_UNUSED notes are fundamentally different > from the other cases though. If a register is unused then its natural > state is to remain unused. The register will only become used if somethin= g > goes out of its way to add new uses of an instruction result that "just > happens to be there". That's a deliberate decision and needs some > analysis to prove that it's safe. Requiring the pass to clear REG_UNUSED > notes too doesn't seem like a significant extra burden. >=20 > Trying to reduce false-negative REG_UNUSED notes is different, > since deleting any instruction could in principle make a register > go from used to unused. Same for REG_DEAD notes: if a pass deletes > an instruction with a REG_DEAD note then it shouldn't have to figure > out where the new death occurs. >=20 > Not sure how representative this is, but I tried the hack below > to flag cases where single_set is used in passes that don't have > up-to-date notes, then ran it on execute.exp. The checking fired > for every version of every test. The collected passes were: >=20 > single_set: bbro > single_set: cc_fusion > single_set: ce1 > single_set: ce2 > single_set: ce3 > single_set: cmpelim > single_set: combine > single_set: compgotos > single_set: cprop > single_set: dwarf2 > single_set: fold_mem_offsets > single_set: fwprop1 > single_set: fwprop2 > single_set: gcse2 > single_set: hoist > single_set: init-regs > single_set: ira > single_set: jump2 > single_set: jump_after_combine > single_set: loop2_done > single_set: loop2_invariant > single_set: postreload > single_set: pro_and_epilogue > single_set: ree > single_set: reload > single_set: rtl_dce > single_set: rtl pre > single_set: sched1 > single_set: sched2 > single_set: sched_fusion > single_set: sms > single_set: split1 > single_set: split2 > single_set: split3 > single_set: split5 > single_set: subreg3 > single_set: ud_dce > single_set: vartrack > single_set: web >=20 > which is a lot of passes :) >=20 > Some of the calls might be OK in context, due to call-specific > circumstances. But I think it's generally easier to see/show that > a pass is adding new uses of existing defs than it is to prove that > a use of single_set is safe even when notes aren't up-to-date. I think this asks for a verify_notes that checks if notes are conservatively= correct as to our definition then? Not sure if doable for equal/equiv note= s though. Richard=20 > Thanks, > Richard >=20 >=20 > diff --git a/gcc/df-problems.cc b/gcc/df-problems.cc > index d2cfaf7f50f..ece49f041e0 100644 > --- a/gcc/df-problems.cc > +++ b/gcc/df-problems.cc > @@ -3782,6 +3782,8 @@ void > df_note_add_problem (void) > { > df_add_problem (&problem_NOTE); > + extern bool single_set_ok; > + single_set_ok =3D true; > } >=20 >=20 > diff --git a/gcc/passes.cc b/gcc/passes.cc > index 6f894a41d22..d8e12ea2512 100644 > --- a/gcc/passes.cc > +++ b/gcc/passes.cc > @@ -2637,9 +2637,14 @@ execute_one_pass (opt_pass *pass) > do_per_function (verify_curr_properties, > (void *)(size_t)pass->properties_required); >=20 > + extern bool single_set_ok; > + single_set_ok =3D !df; > + > /* Do it! */ > todo_after =3D pass->execute (cfun); >=20 > + single_set_ok =3D !df; > + > if (todo_after & TODO_discard_function) > { > /* Stop timevar. */ > diff --git a/gcc/rtl.h b/gcc/rtl.h > index e4b6cc0dbb5..af3bd1b7cfa 100644 > --- a/gcc/rtl.h > +++ b/gcc/rtl.h > @@ -3607,8 +3607,11 @@ extern void add_auto_inc_notes (rtx_insn *, rtx); >=20 > /* Handle the cheap and common cases inline for performance. */ >=20 > +extern void check_single_set (); > inline rtx single_set (const rtx_insn *insn) > { > + check_single_set (); > + > if (!INSN_P (insn)) > return NULL_RTX; >=20 > diff --git a/gcc/rtlanal.cc b/gcc/rtlanal.cc > index 87267ee3b88..e0207e2753a 100644 > --- a/gcc/rtlanal.cc > +++ b/gcc/rtlanal.cc > @@ -38,6 +38,7 @@ along with GCC; see the file COPYING3. If not see > #include "rtl-iter.h" > #include "hard-reg-set.h" > #include "function-abi.h" > +#include "tree-pass.h" >=20 > /* Forward declarations */ > static void set_of_1 (rtx, const_rtx, void *); > @@ -1543,6 +1544,20 @@ record_hard_reg_uses (rtx *px, void *data) > It may also have CLOBBERs, USEs, or SET whose output > will not be used, which we ignore. */ >=20 > +bool single_set_ok; > +void > +check_single_set () > +{ > + static opt_pass *last_pass; > + if (!single_set_ok > + && current_pass > + && last_pass !=3D current_pass) > + { > + last_pass =3D current_pass; > + fprintf (stderr, "single_set: %s\n", current_pass->name); > + } > +} > + > rtx > single_set_2 (const rtx_insn *insn, const_rtx pat) > {