[Bug rtl-optimization/17808] Scheduler overly conservative in sched-deps

["steven at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From steven at gcc dot gnu dot org  2005-06-28 14:06 -------
It is maybe a bit hard to investigate this bug because it actually causes 
bootstrap failures on e.g. ia64, and even a normal "make" seems to produce 
bad crt* stuff.  So I took a different approach: 
 
Index: common.opt 
=================================================================== 
RCS file: /cvs/gcc/gcc/gcc/common.opt,v 
retrieving revision 1.77 
diff -u -3 -p -r1.77 common.opt 
--- common.opt  28 Jun 2005 02:20:28 -0000      1.77 
+++ common.opt  28 Jun 2005 13:53:10 -0000 
@@ -1014,6 +1014,10 @@ fzero-initialized-in-bss 
 Common Report Var(flag_zero_initialized_in_bss) Init(1) 
 Put zero initialized data in the bss section 
 
+fzzzz 
+Common Report Var(flag_zzzz) Init(0) 
+Flag for testing some feature 
+ 
 g 
 Common JoinedOrMissing 
 Generate debug information in default format 
Index: sched-deps.c 
=================================================================== 
RCS file: /cvs/gcc/gcc/gcc/sched-deps.c,v 
retrieving revision 1.93 
diff -u -3 -p -r1.93 sched-deps.c 
--- sched-deps.c        25 Jun 2005 02:01:03 -0000      1.93 
+++ sched-deps.c        28 Jun 2005 13:53:10 -0000 
@@ -149,7 +149,10 @@ sched_get_condition (rtx insn) 
     return 0; 
 
   src = SET_SRC (pc_set (insn)); 
-#if 0 
+#if 1 
+  if (!flag_zzzz) 
+    return 0; 
+ 
   /* 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 
 
I used this patch and compared the gcc.dg execute.exp results of a normal test 
run with the results of the patched compiler, i.e. the diff of the output of 
 
make check-gcc RUNTESTFLAGS="execute.exp"  
 
and 
 
make check-gcc RUNTESTFLAGS="execute.exp --tool_opts '-fzzzz'" 
 
which shows that on an Itanium2 box the following test cases work with the 
code in sched_get_condition disabled, but fail with the patch: 
0a1,5 
> FAIL: gcc.c-torture/execute/20010209-1.c execution,  -O2 
> FAIL: gcc.c-torture/execute/20010209-1.c execution,  -O3 
-fomit-frame-pointer 
> FAIL: gcc.c-torture/execute/20010209-1.c execution,  -O3 
-fomit-frame-pointer -funroll-loops 
> FAIL: gcc.c-torture/execute/20010209-1.c execution,  -O3 
-fomit-frame-pointer -funroll-all-loops -finline-functions 
> FAIL: gcc.c-torture/execute/20010209-1.c execution,  -O3 -g 
7a13,22 
> FAIL: gcc.c-torture/execute/920625-1.c compilation,  -O3 
-fomit-frame-pointer -funroll-loops 
> FAIL: gcc.c-torture/execute/920625-1.c compilation,  -O3 
-fomit-frame-pointer -funroll-all-loops -finline-functions 
> FAIL: gcc.c-torture/execute/990127-1.c execution,  -O2 
> FAIL: gcc.c-torture/execute/990127-1.c execution,  -O3 -fomit-frame-pointer 
> FAIL: gcc.c-torture/execute/990127-1.c execution,  -O3 -g 
> FAIL: gcc.c-torture/execute/va-arg-10.c execution,  -O2 
> FAIL: gcc.c-torture/execute/va-arg-10.c execution,  -O3 -fomit-frame-pointer 
> FAIL: gcc.c-torture/execute/va-arg-10.c execution,  -O3 -fomit-frame-pointer 
-funroll-loops 
> FAIL: gcc.c-torture/execute/va-arg-10.c execution,  -O3 -fomit-frame-pointer 
-funroll-all-loops -finline-functions 
> FAIL: gcc.c-torture/execute/va-arg-10.c execution,  -O3 -g 
 
There.  At least this should at last make it a bit easier to investigate this 
nasty bug. 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17808