Initialize INSN_COND

Alexander Monakov
Fri Jun 3 17:44:00 GMT 2011

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.


More information about the Gcc-patches mailing list