[Bug rtl-optimization/94728] New: [haifa-sched][restore_pattern] recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL

[Bug rtl-optimization/94728] New: [haifa-sched][restore_pattern] recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL

[xuemaosheng at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94728

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

;;      | insn | prio |                                                         
......................                        
;;      |  387 |   27 | t1=a5==0                       AGS0|AGS1                
;;      |  388 |   27 | pc={(t1!=0)?L184:pc}           PCU                      
;;      |  459 |   26 | ev10=[a0+0xbc0]                AGL0|AGL1   
......................


;;        1--> +  387 t1=a5==0                                :AGS0|AGS1 

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}                    :PCU     
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 similiar code in function apply_replacement (dep_t dep, bool
immediately).

[Bug rtl-optimization/94728] [haifa-sched][restore_pattern] recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94728

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
CCing scheduler people.  Note that discussion & question answering better takes
place on the mailing list gcc@gcc.gnu.org, bugzilla isn't getting much of
attention for this.

[Bug rtl-optimization/94728] [haifa-sched][restore_pattern] recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL

[xuemaosheng at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94728

--- Comment #2 from otcmaf <xuemaosheng at huawei dot com> ---
(In reply to Richard Biener from comment #1)
> CCing scheduler people.  Note that discussion & question answering better
> takes place on the mailing list gcc@gcc.gnu.org, bugzilla isn't getting much
> of attention for this.

Thanks a lot!

[Bug rtl-optimization/94728] [haifa-sched][restore_pattern] recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94728

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abel at gcc dot gnu.org
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
On the high level the analysis makes sense to me, but as this is predication in
Haifa scheduler this is not really my domain :)  The bugreport is also missing
a testcase and information about the target.

I see the reporter has just sent an email to the gcc@ mailing list, so I'm
closing the report: https://gcc.gnu.org/pipermail/gcc/2020-April/232192.html

[Bug rtl-optimization/94728] [haifa-sched][restore_pattern] recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL

[xuemaosheng at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94728

--- Comment #4 from otcmaf <xuemaosheng at huawei dot com> ---
(In reply to Alexander Monakov from comment #3)
> On the high level the analysis makes sense to me, but as this is predication
> in Haifa scheduler this is not really my domain :)  The bugreport is also
> missing a testcase and information about the target.
> 
> I see the reporter has just sent an email to the gcc@ mailing list, so I'm
> closing the report: https://gcc.gnu.org/pipermail/gcc/2020-April/232192.html

OK! Thanks a lot!