Re: Incorrect DFA scheduling of output dependency.

[Daniel Towner <daniel dot towner at picochip dot com>]

Vlad, et al.,

> > I was wrong here. The instruction sequence is actually a data 
> > (read-after-write) dependency, not an output dependency 
> > (write-after-write). However, the relevent portion of the scheduler 
> > dump is as follows:
> >
> > (note 82 147 64 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> >
> > (insn:TI 64 82 150 2 (set (reg/v:HI 4 R4 [orig:25 rdIndex ] [25])
> >        (const_int 0 [0x0])) 15 {movhi} (nil)
> >    (nil))
> >
> > (note 150 64 133 2 NOTE_INSN_LOOP_END)
> >
> > (insn 133 150 135 2 (set (reg:HI 5 R5 [33])
> >        (ashift:HI (reg/v:HI 4 R4 [orig:25 rdIndex ] [25])
> >            (const_int 2 [0x2]))) 48 {ashlhi3} (insn_list:REG_DEP_ANTI 
> > 64 (nil))
> >    (expr_list:REG_EQUAL (ashift:HI (reg/v:HI 4 R4 [orig:25 rdIndex ] 
> > [25])
> >            (const_int 2 [0x2]))
> >        (nil)))
> >
> > Does this state that insn 133 is anti-dependent on insn 64?
I've discovered that the anti-dependency is inserted by sched_analyze. 
It occurs because of the NOTE_INSN_LOOP_END between the two instructions 
above. This note introduces a move barrier between the instructions, 
which is intended to prevent the two instructions being reordered. 
Currently, this barrier is represented by making the second instruction 
anti-dependent upon the first. For most processors, I guess that such a 
dependency works as expected, but a VLIW machine is able to emit such 
instructions in a single cycle, resulting in an incorrect schedule. It 
feels like this should be a true dependency, but the relevent code seems 
to make a distinction between a true dependency  (a TRUE_BARRIER) and a 
order dependency (a MOVE_BARRIER). What sort of dependency should 
actually be inserted here?

thanks,

dan.

============================================================================
Daniel Towner
picoChip Designs Ltd., Riverside Buildings, 108, Walcot Street, BATH,
BA1 5BG
daniel.towner@picochip.com
07786 702589