On Thu, 2020-04-23 at 10:40 +0000, xuemaosheng wrote:
> 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                       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 similar code in function apply_replacement (dep_t dep, bool 
> immediately).
> 
> I think this patch can improve instruction parallelism.
It's a possibility -- it'd need to be tested of course.

I don't think anyone is actively working on improving predication support, so
it's possible that you're going to find more issues.  Also note you were looking
at gcc-7.3.0.  Work like this should be done on the trunk -- that's what you'll
need to test against and produce patches against.

jeff

Reply via email to