This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

sched-ebb.c bug (was Re: [3.3 branch] IA64 bootstrap failure)

On Wed, Jul 09, 2003 at 06:38:00PM +0200, Jakub Jelinek wrote:
> I believe it must be scheduler.
> I've managed to reproduce it on gcc-3_3-rhl-branch, with:
> -quiet -v -I. -Ijava -I../../gcc -I../../gcc/java -I../../gcc/config -I../../gcc/../include -iprefix stage2/../lib/gcc-lib/ia64-redhat-linux/3.3/ -isystem include -isystem stage2/include -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -DIN_GCC -DHAVE_CONFIG_H ../../gcc/java/decl.c -quiet -dumpbase decl.c -auxbase-strip java/decl.s5 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -version -o java/decl.s
> I get different output (the 2 swapped insns posted before by Andreas) than with:
> -quiet -v -I. -Ijava -I../../gcc -I../../gcc/java -I../../gcc/config -I../../gcc/../include -iprefix stage2/../lib/gcc-lib/ia64-redhat-linux/3.3/ -isystem include -isystem stage2/include -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -DIN_GCC -DHAVE_CONFIG_H ../../gcc/java/decl.c -quiet -dumpbase decl.c -auxbase-strip java/decl.s5 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -version -o java/decl.s -dM
> which definitely should not change single iota.

Ok, here is where I got so far in debugging this:
The problem is related to use_cselib by sched-ebb.c.

Particularly, add_insn_mem_dependence on
(set (mem/s:DI (reg/f:DI 15 r15 [1714]) [0 <variable>.type.values+0 S8 A64])
  if (current_sched_info->use_cselib)
      mem = shallow_copy_rtx (mem);
      XEXP (mem, 0) = cselib_subst_to_values (XEXP (mem, 0));
and stores that mem with (value:DI) into deps->pending_write_mems
list (this is while processing:
(insn 3305 3297 3309 0 0x2000000000dfe160 (cond_exec (eq (reg:BI 262 p6 [1716])
            (const_int 0 [0x0]))
        (set (mem/s:DI (reg/f:DI 15 r15 [1714]) [0 <variable>.type.values+0 S8 A64])
            (reg/v/f:DI 8 r8 [1696]))) 424 {mf+7} (insn_list:REG_DEP_ANTI 10859 (insn_list:REG_DEP_ANTI 3293 (insn_list:REG_DEP) (expr_list:REG_DEAD (reg/f:DI 15 r15 [1714])
by sched_analyze_2.
Later on, when sched_analyze calls cselib_process_insn on:
(insn 3312 3319 3324 0 0x2000000000dfe160 (set (reg/f:DI 15 r15 [1724])
        (plus:DI (reg/v/f:DI 8 r8 [1696])
            (const_int 88 [0x58]))) 101 {adddi3} (insn_list:REG_DEP_ANTI 3296 (insn_list:REG_DEP_ANTI 3305 (insn_list:REG_DEP_O)    (nil))
unchain_one_elt_loc_list kills one location in rt_cselib and soon afterwards
discard_useless_locs kills the other one and finally
remove_useless_values puts that rt_cselib (which is still referenced from
(set (value:DI) [0 <variable>.type.values+0 S8 A64])
on one of the deps->pending_write_mems) is put onto empty_vals and reused
for something else.

When schedule_block is run later on, it depends on what rt_cselib
has been reused for, sometimes true_dependence will return true, sometimes
false, which determines what insns are added on INSN_DEPEND list and the
length of INSN_DEPEND list matters when sorting instructions in ready list
(if they have the same rank but different INSN_DEPEND list lengths,
the one with longer INSN_DEPEND list is scheduled first, while if
they have same length, the one with smaller LUID gets scheduled first).

Dunno what the right fix for this should be.
Maybe add a flag to cselib, such that remove_useless_values is never called
from cselib_process_insn if called from sched-deps.c.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]