From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 8FB303858C35 for ; Mon, 4 Dec 2023 02:56:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8FB303858C35 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 8FB303858C35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::42b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701658586; cv=none; b=FD51mRzgAQqv830Z4SbN3mAIXJfydKZuM36Pc1w8FCsahaTTm6Aal7yB0+mZATF17oCcovXtGPFnuaMAgFf+nwOmXg0mxCbv50LLNXi7pKC9rUI7QHPO/JETraxYE7yVqqFjCJFLne3hmVXMILTTUir1BYFkQgm2OM0oI6zM3dk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701658586; c=relaxed/simple; bh=laKXYe2hdV65YmKV5MBckwZUCX2arEXzYZqgoSC94iI=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=ZRSEOWoujbX98xZqOgRncWpGK98sF+2E7gtADUvwl+Vje1vd4kXRohIae1ZvPW3lD663+Uee2iWq/c21PAXIqKNyOC+zG72cMlA+2WGFfH8ZxFFxHuYYyo6S9wBQhAJnwfeUxaEcyXAw6OYSK2kn8T9VWs4vMzXQa0pgotA78jE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-6ce46b78c1bso145914b3a.1 for ; Sun, 03 Dec 2023 18:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701658583; x=1702263383; darn=gcc.gnu.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mR9OjWBp+0ydRN8t9OyEfuJ19YEl9n32id/gQWFgotI=; b=KBRW9i9Pi/HgT4ccXrpqaLwNS76AdYvVvuRK4xu0aZpUimSOeDXMl/Z1g5QHYrZRWn QSetA2ul2s3+0Ps9Eqpn46yXLDmMg2+6ggv8+ZykMpkJzUEOmpQMpyaEn1k/n+UtHLpE 4hAmBc+ILO33izqghBCmaxKpt+5INKHrD/51sVBIeHrLvQcNVvve/7qyiGszbBv5pclB y5k0eJ3CSaHr9nbXf25+FZPR4zPVEiTwkcJ2nCn6XakeMXhRpibKi6Cb1s7f2gdU/JXW sqs6aCTr8fAx/wdB7P6GhaJQTu+Wnm3xPoVit1sYUqcKF7JRck1S++J+roTNcA+rj/Yi qhqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701658583; x=1702263383; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mR9OjWBp+0ydRN8t9OyEfuJ19YEl9n32id/gQWFgotI=; b=Q1Wjao+YbSdJjADnUK4J643y7R2jr3DjaIt+wpcp+iIQYabnVfNd1z9aDIb2YVYwx6 jfK/bOEkeE+hLCttObmA70uX04u4snYMt835tbxU3QSBVEZCCGo9bi4+qVZmu9PJBJlj zZBM2pljluOG4alNL6QvdSJSp93JW+kOKQZCGcwPTGuViFJL/3UdDV1thMA48w5gYsXm PjgXTwIgcLwVwRboOnTvONJf7XseMObS5xTJv4D6VviVfGOaa//P6Q/2gQAUTfcccOW6 2u4H3egVD4+WofjKfeD9ZYRg30gGLvvcBJ81RFevZQ+HPGxoD3ErdNFWri0Gf6S6CxWT T+2Q== X-Gm-Message-State: AOJu0Yy9Ih4ee9FZLW+FEFCy7ILCNAcvLn2qhR1JWLQ8ockDggBMvwkY npaSTWUjpzyVdGht63Y650fOyR4qagEK4SAWfgo= X-Google-Smtp-Source: AGHT+IG6idfs4I3ofGAvtrkTD+ndRnYsoYwyOeUtxgNV3voFSgxsukxNOT6v0RGXKQhNDjxkCkNLMt1UkJNaeWOkQyI= X-Received: by 2002:a05:6a20:968a:b0:18f:97c:9289 with SMTP id hp10-20020a056a20968a00b0018f097c9289mr892187pzc.110.1701658583350; Sun, 03 Dec 2023 18:56:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Pinski Date: Sun, 3 Dec 2023 18:56:11 -0800 Message-ID: Subject: Re: [PATCH] pro_and_epilogue: Call df_note_add_problem () if SHRINK_WRAPPING_ENABLED [PR112760] To: Jakub Jelinek , Eric Botcazou , Segher Boessenkool , Jeff Law , gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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: On Sat, Dec 2, 2023 at 3:04=E2=80=AFAM Richard Sandiford wrote: > > Jakub Jelinek writes: > > Hi! > > > > The following testcase ICEs on x86_64-linux since df_note_add_problem (= ) > > call has been added to mode switching. > > The problem is that the pro_and_epilogue pass in > > prepare_shrink_wrap -> copyprop_hardreg_forward_bb_without_debug_insn > > uses regcprop.cc infrastructure which relies on accurate REG_DEAD/REG_U= NUSED > > notes. E.g. regcprop.cc > > /* We need accurate notes. Earlier passes such as if-conversion may > > leave notes in an inconsistent state. */ > > df_note_add_problem (); > > documents that. On the testcase below it is in particular the > > /* Detect obviously dead sets (via REG_UNUSED notes) and remove t= hem. */ > > if (set > > && !RTX_FRAME_RELATED_P (insn) > > && NONJUMP_INSN_P (insn) > > && !may_trap_p (set) > > && find_reg_note (insn, REG_UNUSED, SET_DEST (set)) > > && !side_effects_p (SET_SRC (set)) > > && !side_effects_p (SET_DEST (set))) > > { > > bool last =3D insn =3D=3D BB_END (bb); > > delete_insn (insn); > > if (last) > > break; > > continue; > > } > > case where a stale REG_UNUSED note breaks stuff up (added in vzeroupper > > pass, redundant insn after it deleted later). > > > > The following patch makes sure the notes are not stale if shrink wrappi= ng > > is enabled. > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > I still maintain that so much stuff relies on the lack of false-positive > REG_UNUSED notes that (whatever the intention might have been) we need > to prevent the false positive. Like Andrew says, any use of single_set > is suspect if there's a REG_UNUSED note for something that is in fact use= d. > > So sorry to be awkward, but I don't think this is the way to go. I think > we'll just end up playing whack-a-mole and adding df_note_add_problem to > lots of passes. > > (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.) Just FYI. This issue with single_use did come up back in 2009 but it seems like it was glossed over until now. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D40209#c5 and the other comments in that bug report where the patch which fixed the ICE was just about doing the add of df_note_add_problem . We definitely need to figure out what should be done here for single_use; split off the use of REG_UNUSED from single_use and use df_single_use for that like what was mentioned there. Or just add df_note_add_problem in other places or fix postreload not to the wrong thing (but there are definitely other passes like mentioned in that bug report that does not update REG_UNUSED, e.g. gcse). Thanks, Andrew > > Richard > > > 2023-12-02 Jakub Jelinek > > > > PR rtl-optimization/112760 > > * function.cc (thread_prologue_and_epilogue_insns): If > > SHRINK_WRAPPING_ENABLED, call df_note_add_problem before calling > > df_analyze. > > > > * gcc.dg/pr112760.c: New test. > > > > --- gcc/function.cc.jj 2023-11-07 08:32:01.699254744 +0100 > > +++ gcc/function.cc 2023-12-01 13:42:51.885189341 +0100 > > @@ -6036,6 +6036,11 @@ make_epilogue_seq (void) > > void > > thread_prologue_and_epilogue_insns (void) > > { > > + /* prepare_shrink_wrap uses copyprop_hardreg_forward_bb_without_debu= g_insn > > + which uses regcprop.cc functions which rely on accurate REG_UNUSE= D > > + and REG_DEAD notes. */ > > + if (SHRINK_WRAPPING_ENABLED) > > + df_note_add_problem (); > > df_analyze (); > > > > /* Can't deal with multiple successors of the entry block at the > > --- gcc/testsuite/gcc.dg/pr112760.c.jj 2023-12-01 13:46:57.44474= 6529 +0100 > > +++ gcc/testsuite/gcc.dg/pr112760.c 2023-12-01 13:46:36.729036971 +01= 00 > > @@ -0,0 +1,22 @@ > > +/* PR rtl-optimization/112760 */ > > +/* { dg-do run } */ > > +/* { dg-options "-O2 -fno-dce -fno-guess-branch-probability --param=3D= max-cse-insns=3D0" } */ > > +/* { dg-additional-options "-m8bit-idiv -mavx" { target i?86-*-* x86_6= 4-*-* } } */ > > + > > +unsigned g; > > + > > +__attribute__((__noipa__)) unsigned short > > +foo (unsigned short a, unsigned short b) > > +{ > > + unsigned short x =3D __builtin_add_overflow_p (a, g, (unsigned short= ) 0); > > + g -=3D g / b; > > + return x; > > +} > > + > > +int > > +main () > > +{ > > + unsigned short x =3D foo (40, 6); > > + if (x !=3D 0) > > + __builtin_abort (); > > +} > > > > Jakub