From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id B73F9385741D for ; Wed, 27 Jul 2022 06:58:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B73F9385741D Received: by mail-ej1-x62f.google.com with SMTP id fy29so29776555ejc.12 for ; Tue, 26 Jul 2022 23:58:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EgC8dhFHITVnGgvcDS/1TsQ07mQ31zg6K9qQ5FhnrMw=; b=IPUAFOdzE8ULEmLtNhi5FLlh5nAlUKwRKt2wb0omymYwZ5n7zBnhFqP5tz2LhzPAHi pY6pWEkZdJDkXbBlr9zDk+OrdlfPtOAYdOro/aO7x8PmVYbC1TzFkob8CTfT8GV+kFwk 4No4yeDXU99uRuJTYSpWWJNV/Rclr4ZNDqpcZVRF9mIcPii7yg2L+KkuOI40VUl/DY0B LhS0UxVrbtlFKZcexT/AbpYLkfZns6fY/zpfMD//HfLLczmTMH3iXhsSlAkmzndYBxcg iTJtKnjBx14JqeK2zbUnaJs9VHM+38FSful/DBemlhAVa4Q5l5q4A8T/lRO9H/4fDoql jzZQ== X-Gm-Message-State: AJIora9cX1KMYZi8GCpU6hFb4An5qYv9IwQQHBbIJDHSIbzyf4Id3azr eZujvBvCOJzLk5vupc6MZ6ZDUwXoikb4uYVDlpI= X-Google-Smtp-Source: AGRyM1tRRkfSIcsY8C3FmtRqtet6AsO7AWGjtxcMUdD1BCao6ZA8APiZ8tiiX1TNt3BXESRXvW/62GaB2cfoX3lftf8= X-Received: by 2002:a17:907:608d:b0:72f:191b:7625 with SMTP id ht13-20020a170907608d00b0072f191b7625mr17027595ejc.754.1658905130232; Tue, 26 Jul 2022 23:58:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Wed, 27 Jul 2022 08:58:38 +0200 Message-ID: Subject: Re: [RFC] Analysis of PR105586 and possible approaches to fix issue To: Surya Kumari Jangala Cc: GCC Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2022 06:58:53 -0000 On Tue, Jul 26, 2022 at 8:55 PM Surya Kumari Jangala via Gcc wrote: > > Hi, > I am working on PR105586. This is a -fcompare-debug failure, with the dif= ferences starting during sched1 pass. The sequence of two instructions in a= basic block (block 4) is flipped with -g. > In addition to this, another difference is that an insn is assigned a dif= ferent cycle in debug vs non-debug modes. > More specifically, the 2nd instruction in basic block 4 is assigned to cy= cle 0 w/o -g but to cycle 1 w/ -g. I felt that this could be resulting in t= he flipping of the later insns in the bb, so I started to investigate the d= ifference in cycle assignment. > > In the routine schedule_block(), after scheduling an insn(schedule_insn()= ), prune_ready_list() is called if the ready list is not empty. This routin= e goes thru all the insns in the ready list and for each insn it checks if = there is a state transition. If there is no state transition, then INSN_TIC= K(insn) is set to current_cycle+1. > > After scheduling the first insn in bb 4, when prune_ready_list() is calle= d, we see that for the debug mode run, there is no state transition for the= second insn and hence it's INSN_TICK is updated. For the non-debug run, a = state transition exists and the INSN_TICK is not updated. This was resultin= g in the second insn being scheduled in cycle 1 in the debug mode, and in c= ycle 0 in the non-debug mode. > > It turned out that the initial dfa state of the basic block (=E2=80=98ini= t_state=E2=80=99 parameter of schedule_block()) was different in debug and = non-debug modes. > > After scheduling a basic block, it=E2=80=99s current dfa state is copied = to the fall-thru basic block. In other words, the initial dfa state of the = fall thru bb is the current state of the bb that was just scheduled. > > Basic block 4 is the fall-thru bb for basic block 3. In non-debug mode, b= b 3 has only a NOTE insn and hence scheduling of bb 3 is skipped. Since bb = 3 is not scheduled, it=E2=80=99s state is not copied to bb 4. Whereas in de= bug mode, bb3 has a NOTE insn and a DEBUG insn. So bb 3 is =E2=80=9Cschedul= ed=E2=80=9D and it=E2=80=99s dfa state is copied to bb4. [The dfa state of = bb 3 is obtained from it=E2=80=99s parent bb, ie, bb 2]. Hence the initial = dfa state of bb 4 is different in debug and non-debug modes due to the diff= erence in the insns in the predecessor bb (bb 3). > > The routine no_real_insns_p() is called to check if scheduling can be ski= pped for a basic block. This routine checks for NOTE and LABEL insns and it= returns =E2=80=98true=E2=80=99 if a basic block contains only NOTE/LABEL i= nsns. Hence, any basic block which has only NOTE or LABEL insns is not sche= duled. > > To fix the issue of insns being assigned different cycles, there are two = possible solutions: > > 1. Modify no_real_insns_p() to treat a DEBUG insn as a non-real insn (sim= ilar to NOTE and LABEL). With this change, bb 3 will not be scheduled in th= e debug mode (as it contains only NOTE and DEBUG insns). If scheduling is s= kipped, then bb 3=E2=80=99s state is not copied to bb 4 and the initial dfa= state of bb 4 will be same in both debug and non-debug modes > 2. Copy dfa state of a basic block to it=E2=80=99s fall-thru block only i= f the basic block contains =E2=80=98real=E2=80=99 insns (ie, it should cont= ain at least one insn which is not a LABEL, NOTE or DEBUG). This will preve= nt copying of dfa state from bb 3 to bb 4 in debug mode. Do you know why the DFA state is not always copied to the fallthru destination and then copied further even if the block does not contain any (real) insns? It somewhat sounds like premature optimization breaking things here... > I decided to take approach 1 and I changed no_real_insns_p() to check for= DEBUG insns in addition to NOTE and LABEL insns. > > But this resulted in an internal compiler error in the bug's testcase. Th= e reason was that dependency nodes and lists of the insns in a basic block = are not freed after the bb is scheduled. The routine sched_analyze() alloca= tes dependency nodes and lists for each insn in an extended basic block onl= y if the insn is NONDEBUG_INSN or DEBUG_INSN. So in debug mode, the schedul= er allocated dependencies for bb 3 but in non-debug mode, there are no depe= ndencies allocated. The dependencies are freed after all the blocks in a re= gion are scheduled. But the routine to free the dependencies is called for = a bb only if no_real_insns_p() returns true for that bb. With approach 1, n= o_real_insns_p() returns true for bb 3 and hence the dependencies are not f= reed. > > I added some code to not create dependencies if a bb contains only NOTE, = LABEL and DEBUG insns. This makes the test pass but I am hitting an interna= l compiler error during bootstrapping. > > I wish to get some inputs/feedback if approach 1 is the correct way to fi= x the issue, or should I take approach 2. > > Thanks, > Surya