From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 85D14385DC32; Thu, 23 Apr 2020 08:21:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 85D14385DC32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1587630074; bh=k3G9KTrQK1d1P4S3puralVxteZTF25Ei+lsvBUSVZfI=; h=From:To:Subject:Date:From; b=UODP3+H64kTSeEfMqhNMJgp7MjHU+qVFV2gmTZVjNxfkEb6vtrGhnXdZxzwnBDYex V0OL2qgOil4tmQP0jeKS2OLyDnpAXP3p4olqk1YcWpPrRrvW5z/xmM+b9BY6Dz0+nx yBedFnYVKbzgNh4bPmXTusgOnkWn1yjSSuLmgVt0= From: "xuemaosheng at huawei dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/94728] New: [haifa-sched][restore_pattern] recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL Date: Thu, 23 Apr 2020 08:21:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 7.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: xuemaosheng at huawei dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 08:21:14 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94728 Bug ID: 94728 Summary: [haifa-sched][restore_pattern] recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: xuemaosheng at huawei dot com Target Milestone: --- If we add the flag DO_PREDICATION in scheduling ebb, the compiler will try = to predicate the insn when the producer insn has been issued, and put the cons= umer insn into suitable queue. For example as shown in schedule verbose dump: ;; | insn | prio |=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ......................=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 ;; | 387 | 27 | t1=3Da5=3D=3D0 AGS0|AGS1=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ;; | 388 | 27 | pc=3D{(t1!=3D0)?L184:pc} PCU=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ;; | 459 | 26 | ev10=3D[a0+0xbc0] AGL0|AGL1=20=20=20 ...................... ;; 1--> + 387 t1=3Da5=3D=3D0 :AGS0|A= GS1=20 deferring rescan insn with uid =3D 459. ;; dependencies resolved: insn + 459 predicated=20 ;; Ready-->Q: insn + 459: queued for 2 cycles (change queue index) ;; tick updated: insn + 459 into queue with cost=3D2=20 insn 387 is a test insn, insn 388 is a jump insn, insn 459 is a load insn. After predicating, insn 459 convert into this form: [!t1] ev10 =3D [a0+0xbc= 0] and put insn 459 into queue[3]. INSN_TICK (459) =3D 3; After issuing jump insn 388, the compiler will try to resotre pattern in in= sn 459 as shown in the following dump files. ;; Ready list after ready_sort: + 388:94:prio=3D27=20=20= =20=20=20=20=20=20=20=20=20=20=20 ;; Ready list (t =3D 1): + 388:94:prio=3D27=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 [1;1]:388=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ;; 1--> + 388 pc=3D{(t1!=3D0)?L184:pc} :PCU=20= =20=20=20=20 restoring pattern for insn 459=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 deferring rescan insn with uid =3D 459.=20=20=20=20=20=20=20=20=20=20=20=20 However, the INSN_TICK of insn 459 doesn't calculate again. Actually, after restoring pattern, the insn can issue more earlier. If we recalculate the INSN_TICK of insn 459, we will get INSN_TICK (459) = =3D 2, then the load insn 459 can issue at clock t =3D 2 instead of clock t =3D 3. So, can we add the following code to recalculate the INSN_TICK in function restore pattern? restore_pattern (dep_t dep, bool immediately) { rtx_insn *next =3D DEP_CON (dep); int tick =3D INSN_TICK (next); ......................... if (DEP_TYPE (dep) =3D=3D REG_DEP_CONTROL) { if (sched_verbose >=3D 5) fprintf (sched_dump, "restoring pattern for insn %d\n", INSN_UID (next)); haifa_change_pattern (next, ORIG_PAT (next)); + update_insn_after_change (next); + if ((TODO_SPEC (next) & (HARD_DEP | DEP_POSTPONED)) =3D=3D 0) + { + fix_tick_ready (next); + tick =3D INSN_TICK (next); + } } ........................... I found the similiar code in function apply_replacement (dep_t dep, bool immediately).=