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? Can you tell why you chose to place INSN_CONDs into HDID instead of HID? HID seems a bit more natural choice to me, and as it explicitely populated with zeros, it fixes the above combine.c testcase for me. However, moving INSN_CONDs to HID breaks sel-sched in a different way because sometimes HID is not extended early enough; if that approach is generally ok for you, I can see whether I can produce a working patch in that vein. 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. Thanks. Alexander
