> +(define_expand "zero_extendsidi2"
        > +  [(set (match_operand:DI 0 "register_operand")
        > +     (zero_extend:DI (match_operand:SI 1 
"reg_or_indirect_memory_operand")))]
        > +  ""
        > +{
        > +  if (register_operand (operands[1], SImode))
        > +    {
        > +      operands[1] = gen_lowpart (DImode, operands[1]);
        > +      emit_insn (gen_ashldi3 (operands[0], operands[1], GEN_INT 
(32)));
        > +      emit_insn (gen_lshrdi3 (operands[0], operands[0], GEN_INT 
(32)));
        > +      DONE;
        > +    }
        > +})
        > +
        > +(define_insn "*zero_extendsidi2"
        > +  [(set (match_operand:DI 0 "register_operand" "=r,r")
        > +     (zero_extend:DI (match_operand:SI 1 
"reg_or_indirect_memory_operand" "0,m")))]
        > +  ""
        > +  "@
        > +   lsh\t%0,32\n\trsh\t%0,32
        > +   ldxw\t%0,%1"
        > +  [(set_attr "type" "alu,ldx")
        > +   (set_attr "length" "16,8")])
        
        Sorry, should have noticed last time, but: you shouldn't need to handle
        register operands here given the expander above.  It's OK if you find it
        improves code quality, but it'd be interesting to know why if so....
    
    If I remove the 0,=r alternative from the insn above, and also adjust
    the predicate to indirect_memory_operand, then I get a segfault in one
    test, in update_costs_from_allocno (ira-color.c:1382), because:
    
    (gdb) print mode
    $1 = E_SImode
    (gdb) print default_target_ira_int->x_ira_register_move_cost[mode]
    $13 = (move_table *) 0x0
    
    What I think is going on is:
    
    1. The expand above is used, and
    
    2. there is no insn in the program matched by a pattern that involves a
       SI operand, and therefore record_operand_costs is never called on
       SImode operand, and therefore the lazily-initialized
       x_ira_register_move_cost is never filled in for E_SImode, and then
    
    3. ira() -> ira_color() -> color () -> do_coloring () ->
       ira_traverse_loop_tree () -> color_pass () -> color_allocnos () ->
       update_costs_from_prefs () -> update_costs_from_allocno () *CRASH*
    
    Is this a bug, or am I expected to somehow trigger the initialization of
    the SImode entry in the ira register move table in some other way?

This is the backtrace btw:

jemarch@termi:~/gnu/src/gcc-git/build-bpf/gcc$ PATH=.:$PATH ./xgcc -O2 -c 
/home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c
during RTL pass: ira
/home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c: 
In function ‘vq_nbest’:
/home/jemarch/gnu/src/gcc-git/gcc/testsuite/gcc.c-torture/compile/pr39928-2.c:8:1:
 internal compiler error: Segmentation fault
    8 | }
      | ^
0xfa8cb7 crash_signal
        ../../gcc/toplev.c:326
0x7f278d44e05f ???
        
/build/glibc-yWQXbR/glibc-2.24/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xd4ec8b update_costs_from_allocno
        ../../gcc/ira-color.c:1382
0xd4ee09 update_costs_from_prefs
        ../../gcc/ira-color.c:1422
0xd535d9 color_allocnos
        ../../gcc/ira-color.c:3170
0xd53e21 color_pass
        ../../gcc/ira-color.c:3309
0xd39b10 ira_traverse_loop_tree(bool, ira_loop_tree_node*, void 
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
        ../../gcc/ira-build.c:1781
0xd54703 do_coloring
        ../../gcc/ira-color.c:3460
0xd58203 color
        ../../gcc/ira-color.c:4837
0xd58746 ira_color()
        ../../gcc/ira-color.c:4968
0xd34990 ira
        ../../gcc/ira.c:5365
0xd35118 execute
        ../../gcc/ira.c:5663
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

Reply via email to