Vladimir Makarov wrote:
I'll look at this PR today.
We've looked today at this issue. We think the problem is that proposed
patch of sched_get_condition() treats conditional jumps likely to
COND_EXECs, but it doesn't fix other places in sched-deps, where
COND_EXECs are considered. Maxim Kuvyrkov proposed the attached patch,
which allows gcc to bootstrap on ia64 and fixes the testcase in PR.
We've also found that current mainline ICEs compiling the testcase with
"-O0 -fschedule-insns -fschedule-insns2". That is because after reload
several pseudos still remain in global_live_at_start sets. The pseudos
then appear in regsets through compute_jump_reg_dependencies(), and
sched-deps segfaults at EXECUTE_IF_SET_IN_REG_SET loop at sched-deps.c:948.
We don't know reload well enough to know for sure which place should be
fixed in reload, or maybe in update_life_info(). Is this issue worth
opening another PR?
Andrey
--- gcc/gcc/sched-deps.c Sun Jun 19 16:37:49 2005
+++ orig/gcc/sched-deps.c Thu Jun 30 18:00:23 2005
@@ -149,7 +149,7 @@
return 0;
src = SET_SRC (pc_set (insn));
-#if 0
+#if 1
/* The previous code here was completely invalid and could never extract
the condition from a jump. This code does the correct thing, but that
triggers latent bugs later in the scheduler on ports with conditional
@@ -1019,7 +1019,8 @@
{
/* In the case of barrier the most added dependencies are not
real, so we use anti-dependence here. */
- if (GET_CODE (PATTERN (insn)) == COND_EXEC)
+ /* if (GET_CODE (PATTERN (insn)) == COND_EXEC) */
+ if (sched_get_condition (insn))
{
EXECUTE_IF_SET_IN_REG_SET (&deps->reg_last_in_use, 0, i, rsi)
{
@@ -1066,7 +1067,8 @@
{
/* If the current insn is conditional, we can't free any
of the lists. */
- if (GET_CODE (PATTERN (insn)) == COND_EXEC)
+ /* if (GET_CODE (PATTERN (insn)) == COND_EXEC) */
+ if (sched_get_condition (insn))
{
EXECUTE_IF_SET_IN_REG_SET (reg_pending_uses, 0, i, rsi)
{
