Today I find that function haifa_change_pattern also will call function 
update_insn_after_change.

/* Change pattern of INSN to NEW_PAT.  Invalidate cached haifa
   instruction data.  */
static bool
haifa_change_pattern (rtx_insn *insn, rtx new_pat)
{
  int t;

  t = validate_change (insn, &PATTERN (insn), new_pat, 0);
  if (!t)
    return false;

  update_insn_after_change (insn);
  return true;
}

In my opinion, if a insn can convert into a conditional exection insn, it must 
can convert back.
So in order to update the insn tick, I think that adding the following code is 
enough.

restore_pattern (dep_t dep, bool immediately)
{
  rtx_insn *next = DEP_CON (dep);
  int tick = INSN_TICK (next);

.........................

  if (DEP_TYPE (dep) == REG_DEP_CONTROL)
    {
      if (sched_verbose >= 5)
      fprintf (sched_dump, "restoring pattern for insn %d\n",
           INSN_UID (next));
      haifa_change_pattern (next, ORIG_PAT (next));
+    if ((TODO_SPEC (next) & (HARD_DEP | DEP_POSTPONED)) == 0)
+      {
+        fix_tick_ready (next);
+        tick = INSN_TICK (next);
+      }
    }
...........................

In my opinion, a conditional exection insn restore to normal insn, its 
dependence has changed.
It’s reasonable to recalculate INSN_TICK and choose the suitable queue for the 
insn again.
Since in some case, after recalculating INSN_TICK, the normal insn can issue 
earlier.


Best wishes!

发件人: xuemaosheng
发送时间: 2020年4月23日 18:41
收件人: 'gcc@gcc.gnu.org' <gcc@gcc.gnu.org>


Product: GCC
Component: rtl-optimization
Version: 7.3.0


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 consumer insn into suitable queue.  For example as shown in 
schedule verbose dump file:

;;      | insn | prio |
......................
;;      |  387 |   27 | t1=a5==0                       UNIT0|UNIT1
;;      |  388 |   27 | pc={(t1!=0)?L184:pc}           UNIT2
;;      |  459 |   26 | ev10=[a0+0xbc0]                UNIT3|UNIT4
......................


;;        1--> +  387 t1=a5==0                                : UNIT0|UNIT1

deferring rescan insn with uid = 459.
;;              dependencies resolved: insn +  459 predicated
;;              Ready-->Q: insn +  459: queued for 2 cycles (change queue index)
;;              tick updated: insn +  459 into queue with cost=2

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 = [a0+0xbc0]
and put insn 459 into queue[3]. INSN_TICK (459) = 3;

After issuing jump insn 388, the compiler will try to resotre pattern in insn 
459 as shown in the following dump files.

;;              Ready list after ready_sort:      +  388:94:prio=27
;;      Ready list (t =   1):    +  388:94:prio=27
[1;1]:388
;;        1--> +  388 pc={(t1!=0)?L184:pc}                    :UNIT2
restoring pattern for insn 459
deferring rescan insn with uid = 459.

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) = 2, 
then the load insn 459 can issue at clock t = 2 instead of clock t = 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 = DEP_CON (dep);
  int tick = INSN_TICK (next);

.........................

  if (DEP_TYPE (dep) == REG_DEP_CONTROL)
    {
      if (sched_verbose >= 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)) == 0)
+      {
+        fix_tick_ready (next);
+        tick = INSN_TICK (next);
+      }
    }
...........................

I found the similar code in function apply_replacement (dep_t dep, bool 
immediately).

I think this patch can improve instruction parallelism.


Best wishes!

Reply via email to