Dependency confusion in sched-deps

["Paulo Matos" <pmatos@broadcom.com>]

Hello,

I am slightly unsure if the confusion is in the dependencies or it's my confusion.

I have tracked this strange behaviour which only occurs when we need to flush pending instructions due to the pending list becoming too large (gcc 4.8, haven't tried with trunk).

I have two stores: 
85: st zr, [r12] # zr is the zero register
90: st zr, [r18]

While analysing dependencies for `st zr, [r12]`, we notice that pending list is too large in sched_analyze_1 and call flush_pending_lists (deps, insn, false, true).

This in turn causes the last_pending_memory_flush to be set to:
(insn_list:REG_DEP_TRUE 85 (nil))

When insn 90 is analyzed next, it skips the flushing bit since the pending lists had just been flushed and enters the else bit where it does:
	  add_dependence_list (insn, deps->last_pending_memory_flush, 1,
			       REG_DEP_ANTI, true);

This adds the dependency: 90 has an anti-dependency to 85.
I think this should be a true dependency (write after write). It even says so in the list of last_pending_memory_flush, however add_dependence_list function ignored this and uses the dep_type passed: REG_DEP_ANTI.

Is anti the correct dependence? Why?

-- 
Paulo Matos