cond_exec sched-deps failure

[Richard Henderson <rth at redhat dot com>]

On ia64, we can mis-schedule code like

  1	(set (reg:BI cond) (...))

  2	(cond_exec (ne (reg:BI cond) (const_int 0))
	  (set (reg:BI cond) (...)))

  3	(cond_exec (eq (reg:BI cond) (const_int 0))
	  ...)

by scheduling insn 3 before insn 2.  The following hack makes
things work right, but I think the proper solution is to 
recognize that predicate dependancies are different than
other dependancies in the insn.  I don't really feel like
diving into that scale of code re-organization right now.


r~


        * sched-deps.c (add_dependence): Don't elide dependancy if the
        conditional used by insn is modified in elem.

Index: sched-deps.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/sched-deps.c,v
retrieving revision 1.23
diff -c -p -d -r1.23 sched-deps.c
*** sched-deps.c	2001/08/22 14:35:39	1.23
--- sched-deps.c	2001/08/31 17:56:13
*************** add_dependence (insn, elem, dep_type)
*** 213,223 ****
  
    /* flow.c doesn't handle conditional lifetimes entirely correctly;
       calls mess up the conditional lifetimes.  */
    if (GET_CODE (insn) != CALL_INSN && GET_CODE (elem) != CALL_INSN)
      {
        cond1 = get_condition (insn);
        cond2 = get_condition (elem);
!       if (cond1 && cond2 && conditions_mutex_p (cond1, cond2))
  	return;
      }
  
--- 213,228 ----
  
    /* flow.c doesn't handle conditional lifetimes entirely correctly;
       calls mess up the conditional lifetimes.  */
+   /* ??? add_dependence is the wrong place to be eliding dependencies,
+      as that forgets that the condition expressions themselves may
+      be dependent.  */
    if (GET_CODE (insn) != CALL_INSN && GET_CODE (elem) != CALL_INSN)
      {
        cond1 = get_condition (insn);
        cond2 = get_condition (elem);
!       if (cond1 && cond2
! 	  && conditions_mutex_p (cond1, cond2)
! 	  && !modified_in_p (cond1, elem))
  	return;
      }