Re: haifa memory abuse

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

On Wednesday 22 November 2000 20:30, Richard Henderson wrote:
> Consider a function such as
>
> 	void foo()
> 	{
> 	  bar(1);
> 	  bar(2);
> 	  ...
> 	  bar(6000);
> 	}
>
> At present, such a function will take about 1GB to compile.
> This is due to haifa creating _exceedingly_ long dependancy
> chains for the call_insns.
>
> The problem was that we never zapped the reg_last_uses and
> reg_last_sets lists, which meant that each call_insn depended
> on every instruction before it.  Yikes.
>
> This patch, bootstrapped on i686 and alphaev6, reduces peak
> memory usage for the aforementioned function to 12MB.
>
>
> r~
>
>
>         * haifa-sched.c (sched_analyze_1): Don't special-case calls
>         for clobbering registers.
>         (sched_analyze_2): Likewise.
>         (sched_analyze): Zap reg_last_uses and reg_last_sets after calls.

Richard,

this breaks boostrap during stage2 on powerpc-linux-gnu, the generated stage2 
compiler got miscompiled. I think your change uncovered an underlying bug. 
Basically the following insns are involved:

...

(insn 1713 1711 1714 (set (reg:SI 0 r0)
        (reg:SI 65 lr)) 282 {*movsi_internal1} (nil)
    (nil))

...

(insn/f 1748 1746 1750 (set (mem:SI (plus:SI (reg:SI 1 r1)
                (const_int 116 [0x74])) 0)
        (reg:SI 0 r0)) 282 {*movsi_internal1} (insn_list 1713 (insn_list 1711 
(nil)))
    (expr_list:REG_FRAME_RELATED_EXPR (set (mem:SI (plus:SI (reg:SI 1 r1)
                    (const_int 116 [0x74])) 0)
            (reg:SI 65 lr))
        (nil)))

...

(insn 42 64 49 (parallel[
            (set (reg:SI 29 r29)
                (eq:SI (reg/v:SI 29 r29)
                    (const_int 0 [0x0])))
            (clobber (reg:SI 0 r0))
        ] ) 366 {*rs6000.md:10314} (insn_list 4 (nil))
    (nil))

This is the ordering in bb 0 at the time the 2nd scheduler pass (sched2) is 
started, 1713 and 1748 are prologue insns. Now we enter this code in 
schedule_block() around line 6110 in haifa-sched.c:

      /* Issue insns from ready list.  */
      while (ready.n_ready != 0 && can_issue_more)
        {
          /* Select and remove the insn from the ready list.  */
          rtx insn = ready_remove_first (&ready);
          int cost = actual_hazard (insn_unit (insn), insn, clock_var, 0);    
                         
After this loop has run, insn 42 has been moved in front of insn 1748, which 
subsequently breaks the lifetime calculation for r0, which is clobbered in 
insn 42. I suspect the r0 CLOBBER inside the PARALLEL is not correctly taken 
into consideration. What routine would be responsible for recognizing the 
CLOBBER? Some hints would be helpful, since I'm not to familiar with the 
scheduling passes yet.

Here is a backtrace, shortly after the mess has happened:
(gdb) bt
#0  schedule_block (bb=0, rgn_n_insns=51) at 
../../../gccmnp/gcc/haifa-sched.c:6235
#1  0x102f6d68 in schedule_region (rgn=0) at 
../../../gccmnp/gcc/haifa-sched.c:6895
#2  0x102f7850 in schedule_insns (dump_file=0x0) at 
../../../gccmnp/gcc/haifa-sched.c:7149
#3  0x1008732c in rest_of_compilation (decl=0x302f5180) at 
../../../gccmnp/gcc/toplev.c:3564
#4  0x1002b7c4 in c_expand_body (fndecl=0x302f5180, nested_p=0) at 
../../../gccmnp/gcc/c-decl.c:6865
#5  0x1002b3f8 in finish_function (nested=0) at 
../../../gccmnp/gcc/c-decl.c:6786
#6  0x100023e8 in yyparse_1 () at /usr/lib/bison.simple:321
#7  0x10009dbc in yyparse () at ../../../gccmnp/gcc/c-lex.c:246
#8  0x10084ca0 in compile_file (name=0x104a4475 "emit-rtl.i") at 
../../../gccmnp/gcc/toplev.c:2363
#9  0x1008a198 in main (argc=11, argv=0x7ffffbcc) at 
../../../gccmnp/gcc/toplev.c:4844
#10 0xfee3dc8 in __libc_start_main (argc=11, ubp_av=0x7ffffbcc, ubp_ev=0x1f, 
auxvec=0x7ffffc68, rtld_fini=0x7, stinfo=0x103e85f0,
    stack_on_entry=0x7ffff310) at ../sysdeps/powerpc/elf/libc-start.c:116

Franz.