From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id B51E03858409 for ; Tue, 28 Sep 2021 16:05:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B51E03858409 Received: by mail-ed1-x534.google.com with SMTP id ba1so27279149edb.4 for ; Tue, 28 Sep 2021 09:05:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:user-agent:in-reply-to :references:message-id:mime-version:content-transfer-encoding; bh=NXxVYMxJojd7Fm/Rb0gWV/ghWGvZ4QDXRsWbRlMBnjU=; b=sTZ2y7IHPhWry/9n4AHZzmPWRErHPPEHt/Q91KirHyz+TuCVtb0+pZtDYAP1U3epTN PtjhSHy6GKCV5zpyeBcvrLReoer9liiCI/ZzW4ZdQhaofh/9f69CGO8hSL5E8PCrgK5R 2qNJTZZo8xCHWtqiUHCdtAV9yIxbkCO7goOB5pWZxJYFeSCCBhp/Y/v3hwowpRE6xf49 r/nSl+YMTjFZN3AfAXhzrYEik56e6rzBPA90U05uuLsV99A0ZvZECMh9fPbY7X1ACTWY AGQKk9LeuV78WzEDFn4OGaQpiMs8f/xDX6WKCF2794+DDkcRaixoX4qndJKiVnTm5k4G VXSg== X-Gm-Message-State: AOAM530n8Ybwr506Erqvl/gl55rU5Ny/zoYBnZf043K/RCZQvt3KRnxc Tk9Pnk801M47dUP8smErJ+g= X-Google-Smtp-Source: ABdhPJw2yAbEE38KsT4A4OmyhRXafktPGoBhSYCYYt3aPZEX/6nj8QmeXT2fKVr00mXrpm92V2rHHw== X-Received: by 2002:a05:6402:288f:: with SMTP id eg15mr8481651edb.356.1632845154283; Tue, 28 Sep 2021 09:05:54 -0700 (PDT) Received: from [127.0.0.1] (dynamic-095-114-111-160.95.114.pool.telefonica.de. [95.114.111.160]) by smtp.gmail.com with ESMTPSA id u4sm10690724ejc.19.2021.09.28.09.05.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Sep 2021 09:05:53 -0700 (PDT) Date: Tue, 28 Sep 2021 18:05:52 +0200 From: Richard Biener To: Jeff Law , Jeff Law via Gcc-patches , Aldy Hernandez , GCC patches Subject: Re: [PATCH] Improve jump threading dump output. User-Agent: K-9 Mail for Android In-Reply-To: References: <20210928094545.889111-1-aldyh@redhat.com> <9f2db536-c182-426e-05d5-0242d9a109f1@gmail.com> <25abc6f7-8006-5cf5-95bf-bd752a46e9ea@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2021 16:06:00 -0000 On September 28, 2021 5:45:52 PM GMT+02:00, Jeff Law via Gcc-patches wrote: > > >On 9/28/2021 7:53 AM, Aldy Hernandez wrote: >> >> >> On 9/28/21 3:47 PM, Jeff Law wrote: >>> >>> >>> On 9/28/2021 3:45 AM, Aldy Hernandez wrote: >>>> In analyzing PR102511, it has become abundantly clear that we need >>>> better debugging aids for the jump threader solver=2E=C2=A0 Currently >>>> debugging these issues is a nightmare if you're not intimately >>>> familiar with the code=2E=C2=A0 This patch attempts to improve this= =2E >>>> >>>> First, I'm enabling path solver dumps with TDF_THREADING=2E None of t= he >>>> available TDF_* flags are a good match, and using TDF_DETAILS would= =20 >>>> blow >>>> up the dump file, since both threaders continually call the solver to >>>> try out candidates=2E=C2=A0 This will allow dumping path solver detai= ls=20 >>>> without >>>> having to resort to hacking the source=2E >>>> >>>> I am also dumping the current registered_jump_thread dbg counter used >>>> by the registry, in the solver=2E=C2=A0 That way narrowing down a pro= blematic >>>> thread can then be examined by -fdump-*-threading and looking at the >>>> solver details surrounding the appropriate counter (which the dbgcnt >>>> also dumps to the dump file)=2E >>>> >>>> You still need knowledge of the solver to debug these issues, but at >>>> least now it's not entirely opaque=2E >>>> >>>> OK? >>>> >>>> gcc/ChangeLog: >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0* dbgcnt=2Ec (dbg_cnt_counter): New=2E >>>> =C2=A0=C2=A0=C2=A0=C2=A0* dbgcnt=2Eh (dbg_cnt_counter): New=2E >>>> =C2=A0=C2=A0=C2=A0=C2=A0* dumpfile=2Ec (dump_options): Add entry for = TDF_THREADING=2E >>>> =C2=A0=C2=A0=C2=A0=C2=A0* dumpfile=2Eh (enum dump_flag): Add TDF_THRE= ADING=2E >>>> =C2=A0=C2=A0=C2=A0=C2=A0* gimple-range-path=2Ecc (DEBUG_SOLVER): Use = TDF_THREADING=2E >>>> =C2=A0=C2=A0=C2=A0=C2=A0* tree-ssa-threadupdate=2Ec (dump_jump_thread= _path): Dump out >>>> =C2=A0=C2=A0=C2=A0=C2=A0debug counter=2E >>> OK=2E >>> >>> Note we've got massive failures in the tester starting sometime=20 >>> yesterday and I suspect all the threader work=2E=C2=A0=C2=A0=C2=A0 So = I'm going to=20 >>> slow down on reviews of that code as we stabilize stuff=2E >> >> Fair enough=2E=C2=A0 Let's knock those out then=2E >So several are failing gcc=2Edg/loop-unswitch-3=2Ec=2E > >This test appears to be verifying that we unswitch a test in one of the= =20 >loops, which is no longer happening after the change to replace the VRP= =20 >threader with the hybrid forward threader=2E > >So both the old VRP threader and the new style identify and realize a=20 >single jump thread=2E > >In the old VRP threader realization of the jump thread ends up creating= =20 >nested loops=2E=C2=A0 In the new implementation we end up creating a sing= le=20 >loop with two back edges to the header=2E > >ie, the (partial) graphs look like this > >OLD > > =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 1<--+ > =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | >+->=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0 | >|=C2=A0 =C2=A0 /=C2=A0=C2=A0 \=C2=A0=C2=A0 | >|=C2=A0 3=C2=A0=C2=A0=C2=A0=C2=A0 4=C2=A0 | >+- +=C2=A0=C2=A0=C2=A0=C2=A0 +-+ > >NEW > > >+->=C2=A0 2 <-+ >|=C2=A0=C2=A0=C2=A0 /=C2=A0=C2=A0 \=C2=A0=C2=A0 | >|=C2=A0 3=C2=A0=C2=A0=C2=A0=C2=A0 4=C2=A0 | >+- +=C2=A0=C2=A0=C2=A0=C2=A0 +-+ > > >I wonder if we're not doing proper loop fixups or something similar=20 >after that change=2E=C2=A0 IIRC we have/had bits in the copier and CFG up= date=20 >code to mark the loops that need re-analysis and fixing up=2E > >Anyway, you should be able to trigger and analyze with a cross compiler= =2E > >I've got to switch to my day job, but I'll pass along more as I get a=20 >chance to look at them=2E If you're stuck I'm also happy to help=2E Note that relying on loop fixup = is almost never good because we easily lose track of loop association of in= fo like OMP simd loops and all loop pragmas=2E=20 Richard=2E=20 >jeff > > >