-funroll-loops regression in gcc3.0

Dale Johannesen dalej@apple.com
Fri Apr 27 09:48:00 GMT 2001


On Thursday, April 26, 2001, at 04:05  PM, dalej@apple.com wrote:

> int foo;
> void f(int p[4]) {
>   int i;
>   if ( foo )
>     for ( i=0; i<4; i++ )
>       p[i] = 0;
>   else
>     for ( i=0; i<4; i++ )
>       p[i] = foo;
> }
>
> Try this with -O3 -funroll-loops.  The first loop isn't unrolled (I'm 
> on Darwin, but I'm fairly sure the target doesn't matter).  This is a 
> regression from gcc2.95.
>
> The code at the bottom of the first loop originally looks like this:
>
> (jump_insn/i 113 112 114 (set (pc)...    ; conditional, to top of loop
>
> (jump_insn/i 114 113 115 (set (pc)   ; unconditional, out of loop 
> (forward)
>          (label_ref 119)) -1 (nil)      (nil))
>
> (barrier/i 115 114 116)
>
> (jump_insn/i 116 115 117 (set (pc)        ; dead, unreachable
>          (label_ref 100)) -1 (nil)     (nil))
>
> (barrier/i 117 116 118)
>
> (note/i 118 117 119 NOTE_INSN_LOOP_END)
>
> (code_label/i 119 118 120 117 "" "" [0 uses])
>
> (jump_insn/i 120 119 121 (set (pc)
>          (label_ref 123)) -1 (nil)
>      (nil))
>
> The jump_optimize() phase in 2.95 behaves differently from that in 3.0.
> Both eliminate the dead insn 116 first.  Then 2.95 eliminates branches
> to the following instruction, so 114 goes away.  But 3.0 does
> branch-to-branch elimination instead, so 114 becomes a branch to 123,
> and 120 goes away.  The difference is that in 3.0 the remaining jump is
> inside the LOOP, where it doesn't belong; this confuses the unrolling
> code.  (And possibly other code, for all I know.)
>
> I tried to fix this by copying the branch-to-following removal up  
> (doing it twice).
> That works on this example, but got some kind of crash in gcc.c when 
> bootstrapping.
> (That was at a time when there were some other problems in jump.c, so 
> I'll try it again
> overnight.)

I've confirmed that this crash still happens, so I'll back out my 
attempted fix.

stage1/xgcc -Bstage1/ -B/usr/local/powerpc-apple-darwin1.3/bin/  
-DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  
-DHAVE_CONFIG_H    -I. -I. -I../../gcc3/gcc -I../../gcc3/gcc/. 
-I../../gcc3/gcc/config -I../../gcc3/gcc/../include \
   -DSTANDARD_STARTFILE_PREFIX=\"../../../\" 
-DSTANDARD_EXEC_PREFIX=\"/usr/local/lib/gcc-lib/\" 
-DDEFAULT_TARGET_VERSION=\"3.1\" 
-DDEFAULT_TARGET_MACHINE=\"powerpc-apple-darwin1.3\" 
-DSTANDARD_BINDIR_PREFIX=\"/usr/local/bin/\" 
-DTOOLDIR_BASE_PREFIX=\"../../../../\" `test "${SHLIB_LINK}" -a "yes" = 
"yes" && echo "-DENABLE_SHARED_LIBGCC"` `test "${SHLIB_MULTILIB}" && 
echo "-DNO_SHARED_LIBGCC_MULTILIB"` \
   -c ../../gcc3/gcc/gcc.c)
../../gcc3/gcc/gcc.c:624: warning: traditional C rejects string 
concatenation
../../gcc3/gcc/gcc.c:669: warning: string length `899' is greater than 
the length `509' ISO C89 compilers are required to support
../../gcc3/gcc/gcc.c:819: warning: string length `564' is greater than 
the length `509' ISO C89 compilers are required to support
In file included from specs.h:1,
                  from ../../gcc3/gcc/gcc.c:837:
../../gcc3/gcc/cp/lang-specs.h:60: warning: string length `958' is 
greater than the length `509' ISO C89 compilers are required to support
../../gcc3/gcc/cp/lang-specs.h:61: warning: traditional C rejects string 
concatenation
../../gcc3/gcc/gcc.c: In function `translate_options':
../../gcc3/gcc/gcc.c:1126: Insn does not satisfy its constraints:
(insn 1711 1710 1712 (set:SI (reg:SI 0 r0)
         (plus:SI (reg:SI 31 r31)
             (high:SI (const:SI (minus:SI (symbol_ref:SI ("option_map"))
                         (symbol_ref:SI ("*L1$pb"))))))) 37 {addsi3_high} 
(nil)
     (nil))
../../gcc3/gcc/gcc.c:1126: Internal compiler error in 
reload_cse_simplify_operands, at reload1.c:8344

>  It could also be fixed in unroll.c (there is a comment that suggests 
> this, in fact)
> but I'm not sure that will fix the entire problem.  Maybe somebody 
> familiar with jump.c
> could look at this?
>
> (-funroll-all-loops does unroll the first loop, but the code is very 
> ugly.)
>



More information about the Gcc-bugs mailing list