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
