sched2, ret, use, and VLIW bundling

sched2, ret, use, and VLIW bundling

[DJ Delorie]

I'm working on a VLIW coprocessor for MeP.  One thing I noticed is
that sched2 won't bundle the function's RET with the insn that sets
the return value register, apparently because there's an intervening
USE of that register (insn 30 in the example below).

Is there any way around this?  The return value obviously isn't
actually used there, nor does the return insn need it - that USE is
just to keep the return value live until the function exits.


sched_reorder: clock 3 nready 1
insn  671   27  cgen_intrinsic_cpadd3_h_P0S_P1  p0s,p1

;;	Ready list (t =   3):    27
;;	  3-->    27 $c0=unspec[$c16,$c0] 1774         :(ivc2_p0+ivc2_slot_p0s)|(ivc2_p1+ivc2_slot_p1)
;;		dependencies resolved: insn 30
;;		tick updated: insn 30 into ready
;;	Ready list (t =   3):    30
;;		Ready list after queue_to_ready:    30
;;		Ready list after ready_sort:    30

sched_reorder: clock 4 nready 1
insn   -1   30  {unknown}  none

;;	Ready list (t =   4):    30
;;	  4-->    30 use $c0                           :nothing
;;		dependencies resolved: insn 36
;;		tick updated: insn 36 into ready
;;	Ready list (t =   4):    36
;;	  4-->    36 {return;use $lp;}                 :(ivc2_core+ivc2_slot_c16)
;;	Ready list (t =   4):  
;;	Ready list (final):  
;;   total time = 4
;;   new head = 9
;;   new tail = 36


(insn:TI 27 19 30 2 dj.c:9 (set (reg/i:DI 48 $c0)
        (unspec:DI [
                (reg:DI 64 $c16 [140])
                (reg:DI 48 $c0 [143])
            ] 1774)) 671 {cgen_intrinsic_cpadd3_h_P0S_P1} (expr_list:REG_DEAD (reg:DI 64 $c16 [140])
        (nil)))

(insn 30 27 35 2 dj.c:9 (use (reg/i:DI 48 $c0)) -1 (nil))

(note 35 30 36 2 NOTE_INSN_EPILOGUE_BEG)

(jump_insn:TI 36 35 37 2 dj.c:9 (parallel [
            (return)
            (use (reg:SI 17 $lp))
        ]) 979 {return_internal} (expr_list:REG_DEAD (reg:SI 17 $lp)
        (nil)))

Re: sched2, ret, use, and VLIW bundling

[Maxim Kuvyrkov]

DJ Delorie wrote:
> I'm working on a VLIW coprocessor for MeP.  One thing I noticed is
> that sched2 won't bundle the function's RET with the insn that sets
> the return value register, apparently because there's an intervening
> USE of that register (insn 30 in the example below).
> 
> Is there any way around this?  The return value obviously isn't
> actually used there, nor does the return insn need it - that USE is
> just to keep the return value live until the function exits.

The problem may be in the dependency cost between the SET (insn 27) and 
the USE (insn 30) being >= 1.  Have you tried using 
targetm.sched.adjust_cost() hook to set the cost of USE to 0?

Anyway, this seems strange, the scheduler should just output the USEs as 
soon as they are ready.  One of the few places this can be forced untrue 
is targetm.sched.dfa_new_cycle() hook; does your port define it?

--
Maxim

Re: sched2, ret, use, and VLIW bundling

[DJ Delorie]

> The problem may be in the dependency cost between the SET (insn 27)
> and the USE (insn 30) being >= 1.  Have you tried using
> targetm.sched.adjust_cost() hook to set the cost of USE to 0?

It doesn't get called for those two insns.

> Anyway, this seems strange, the scheduler should just output the
> USEs as soon as they are ready.

It does - that's the problem.  The SET is setting the register that
the USE is using, so the scheduler won't pack them together.

I want to disable that, since *I* know that the USE is only there to
keep the return value from being optimized away; the value isn't an
actual dependency *there*.

Re: sched2, ret, use, and VLIW bundling

[DJ Delorie]

Some progress... the scheduler is willing to schedule them together if
I define the SCHED_REORDER2 hook (just SCHED_REORDER was
insufficient), and always return the number of ready insns.  In my
case, the VLIW packing restrictions are fully defined by a DFA; I
don't need to further restrict packing.