On 06/03/2011 07:44 PM, Alexander Monakov wrote: > > > On Thu, 2 Jun 2011, Bernd Schmidt wrote: > >> Ok. Although I wonder how sel-sched can end up reusing an entry in >> h_d_i_d? How does it use this machinery? If it's not doing a normal >> forward scan as in sched_analyze, the INSN_COND mechanism may break in >> other ways. > > Indeed, that patch did not completely solve the problem, as stale INSN_CONDs > can still be seen (I have a testcase reduced from combine.c). Selective > scheduler's dependency analysis is certainly not limited to a single pass, as > it will test more dependencies on the fly after e.g. creating bookkeeping. > > Was there some particular breakage you had in mind when mentioning that > INSN_CONDs may break in other ways?
Well, sched-deps expects that we walk the insns sequentially, setting INSN_COND when an insn is seen for the first time, and then setting it to const_true_rtx once the condition is no longer valid for mutex_p comparisons. > Can you tell why you chose to place INSN_CONDs into HDID instead of HID? It's only used in sched-deps.c, during the scan. > FWIW, we have a patch that adds predication support for the selective > scheduler (allowing the scheduler to transform insns into predicated form) > that we plan to submit during this stage1. I have such a patch for sched-ebb. Bernd
