[committed] sched-dep.c patch for unconditional dependencies

[James E Wilson]

The IA-64 compiler is hitting an ICE in sched-ebb.c during the machine
dependent reorg pass.  The cause is some missing dependencies.

We have a sequence like
   jump_insn 1
   (note ... NOTE_INSN_LOOP_BEGIN)
   (cond_exec (eq p8 0) ...)
   jump_insn 2 (ne p8 0) ...
The cond_exec is made a scheduling barrier in order to preserve the loop
begin note, which is necessary to preserve the integrity of the
reg_n_refs info which is loop dependent.  So we end up with a dependency
from the cond_exec to jump_insn 1, and all of the dependency lists are
cleared.  We then notice that jump_insn 2 and the cond_exec are mutex,
so no dependency is created between them.  Since jump_insn 2 now has no
dependencies, the scheduler decides to move it before jump_insn 1, and
now we have a mess.  sched-ebb.c fails because the block structure is
confused.  If sched-ebb.c hadn't failed, would have gotten incorrect
code emitted.

The flaw here is that dependencies created for structural reasons
(instead of data flow reasons) must always be unconditional.  This was
broken a few months ago when code was added to try to correctly add
dependencies for COND_EXEC instructions.

This patch adds a new UNCOND argument to some of the functions, so that
we can unconditionally add dependencies when necessary.  I went through
the sched-deps.c code, identified everyplace where we are creating a
structural dependency, and made them unconditional.

I tested this with an IA-64 linux bootstrap and make check for all
default languages.  There were no regressions.

I have checked in the patch.

My work here is not quite finished though.  While looking at this, I
noticed another flaw.  The code is trying to use
last_pending_memory_flush both as a scheduling barrier, and as a list of
pending jump insns.  Unfortunately, this can not work, because
scheduling barriers require unconditional dependencies, and the pending
jump insns don't want unconditional dependencies.  The list of
jump_insns needs to be separate from the last_pending_memory_flush.  I
left this broken for now.  I plan to create a new PR for it.  I think I
can created a testcase by using --param.  A failing case would look
something like
    jump_insn 1
    ....
    jump_insn n-1
    store to foo
    jump_insn n (calls flush_pending_lists)
    load from foo
and now we have no dependency to prevent the load from being moved
before the store.  For now, I suspect this bug won't trigger because we
won't get regions and/or extended basic blocks big enough to trigger it.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.pending.flush.2
Type: text/x-troff-man
Size: 17255 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20051015/3ab75220/attachment.bin>