Re: Patch for scan_loop [Re: EGCS EXTREME optimization times...]

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

Am Sun, 14 Feb 1999 schrieb Jeffrey A Law:
>In message <99021321575600.00950@ns1102.munich.netsurf.de>you write:
>
>  FAIL: gcc.c-torture/compile/980329-1.c,  -O2 -fomit-frame-pointer
>  > -finline-functions -funroll-all-loops
>  > 
>  > I'm a little bit worried about that, cause this thread implied that this
>  > patch should only improve compilation speed and not change the behaviour
>  > of the compiler.
>  > 
>  > Thoughts?
>Odd.  Debug it.
>
>ie, first verify that it actually changed the code and that we're not getting
>some spurious testing problem.
>
>Then we'll start looking at the loop dumps to see what changed.
>
>This is a prime opportunity to learn a little about debugging testcases, then
>debugging the compiler.

Ok,

here's the debug output of cc1 before the loop.c patch:

#0  0x189085c in single_set (insn=0x0) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/rtlanal.c:623
623       if (GET_RTX_CLASS (GET_CODE (insn)) != 'i')
(gdb) l
618          rtx insn;
619     {
620       rtx set;
621       int i;
622
623       if (GET_RTX_CLASS (GET_CODE (insn)) != 'i')
624         return 0;
625
626       if (GET_CODE (PATTERN (insn)) == SET)
627         return PATTERN (insn);
(gdb) bt
#0  single_set (insn=0x0) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/rtlanal.c:623
#1  0x18d5dec in can_reverse_comparison_p (comparison=0x0, insn=0x1a95ec8) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/jump.c:3031
#2  0x18d71fc in invert_exp (x=0x1a95e98, insn=0x1a95ec8) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/jump.c:3995
#3  0x18d72c8 in invert_exp (x=0x1a95e88, insn=0x1a95ec8) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/jump.c:4012
#4  0x18f8104 in copy_loop_body (copy_start=0x1a8d360, copy_end=0x1a8d488, map=0x7fffcc20, exit_label=0x1a95e10, last_iteration=0, unroll_type=UNROLL_NAIVE,
    start_label=0x1a8d320, loop_end=0x1a8d5f0, insert_before=0x1a8d5f0, copy_notes_from=0x1a8d5f0) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/unroll.c:1974
#5  0x18f72d4 in unroll_loop (loop_end=0x1a8d5f0, insn_count=704, loop_start=0x1a8d360, end_insert_before=0x1a8d608, strength_reduce_p=27750088)
    at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/unroll.c:1268
#6  0x18efd44 in strength_reduce (scan_start=0x1a8d320, end=0x1a8d5f0, loop_top=0x0, insn_count=1, loop_start=0x1a8d360, loop_end=0x1a8d5f0, unroll_p=1)
    at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/loop.c:3637
#7  0x18ebca4 in scan_loop (loop_start=0x1a8d360, end=0x1a8d5f0, nregs=176, unroll_p=1) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/loop.c:1082
#8  0x18eab08 in loop_optimize (f=0x1a76ec8, dumpfile=0x1a95ec8, unroll_p=1) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/loop.c:537
#9  0x1827da8 in rest_of_compilation (decl=0x1a89e08) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/toplev.c:3521
#10 0x1812ae8 in finish_function (nested=0) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/c-decl.c:7182
#11 0x18018fc in yyparse () at c-parse.y:313
#12 0x18268b0 in compile_file (name=0x15f90 <Address 0x15f90 out of bounds>) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/toplev.c:2768
#13 0x182a05c in main (argc=10, argv=0x7ffffb44, envp=0x1a95e50) at /home/fsirl/egcs/BUILD/egcs-1.1.1/gcc/toplev.c:4838
#14 0x16df8f4 in __libc_start_main () at ../sysdeps/powerpc/elf/libc-start.c:106
(gdb) p debug_rtx(0x1a95ec8)

(jump_insn 389 388 0 (set (pc)
        (if_then_else (gt (reg:CC 146)
                (const_int 0))
            (label_ref 0)
            (pc))) -1 (nil)
    (nil))
$2 = void
(gdb) p debug_rtx(0x1a95e98)

(if_then_else (gt (reg:CC 146)
        (const_int 0))
    (label_ref 0)
    (pc))
$3 = void

single_set() segfaults cause the code in can_reverse_comparison_p() calls
prev_nonnote_insn() without checking the returned insn for NULL:

3029        {
3030          rtx prev = prev_nonnote_insn (insn);
3031          rtx set = single_set (prev);
3032
3033          if (set == 0 || SET_DEST (set) != arg0)

comparison being NULL as argument to can_reverse_comparison_p() maybe
suspicious too.

I've appended the debugging output after gcse (which is identical with/without
the loop.c patch) and .loop of the compiler with the loop patch. Without the
loop patch no .loop is generated, the compiler segfaults before that.

With the patch applied the compiler never reaches can_reverse_comparison_p()
with similar arguments.
Hmm, is it possible that loop.c was miscompiled before during bootstrap? And
that the change to loop.c covers this?

Franz.

loop.tar.gz