cond_exec sched-deps failure
Richard Henderson
rth@redhat.com
Fri Aug 31 11:08:00 GMT 2001
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;
}
More information about the Gcc-patches
mailing list