Incorrect DFA scheduling of output dependency.

[Daniel Towner]

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