On Fri, Jun 06, 2025 at 04:41:21PM +0100, Stafford Horne wrote:
> On Fri, Jun 06, 2025 at 04:20:10PM +0100, Richard Sandiford wrote:
> > Stafford Horne <[email protected]> writes:
> > > Hello,
> > >
> > > This seems to be causing a build regression on the or1k port.
> > >
> > > I have not quite figured it out yet but I have bisected to this commit.
> > >
> > > The failure is as below, this seems to be caused by the cstoresi4
> > > instruction produced by
> > > or1k.md. So I think its likely something we are doing funny in the port.
> > >
> > > Thanks to Jeff for pointing this out. If you have any idea let me know.
> > >
> > > Log:
> > >
> > > during RTL pass: ce1
> > > dump file: libgcc2.c.286r.ce1
> > > /home/shorne/work/gnu-toolchain/gcc/libgcc/libgcc2.c: In function
> > > '__muldi3':
> > > /home/shorne/work/gnu-toolchain/gcc/libgcc/libgcc2.c:538:1: internal
> > > compiler error: in emit_move_multi_word, at expr.cc:4492
> > > 538 | }
> > > | ^
> > > 0x1b094df internal_error(char const*, ...)
> > >
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/diagnostic-global-context.cc:517
> > > 0x6459c1 fancy_abort(char const*, int, char const*)
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/diagnostic.cc:1815
> > > 0x473a2e emit_move_multi_word
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/expr.cc:4492
> > > 0x93fd7d emit_move_insn(rtx_def*, rtx_def*)
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/expr.cc:4746
> > > 0x9175f1 copy_to_reg(rtx_def*)
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/explow.cc:630
> > > 0xd18977 gen_lowpart_general(machine_mode, rtx_def*)
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/rtlhooks.cc:56
> > > 0x9414c7 convert_mode_scalar
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/expr.cc:818
> > > 0x9421a1 convert_modes(machine_mode, machine_mode, rtx_def*, int)
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/expr.cc:961
> > > 0xc0afa0 prepare_operand(insn_code, rtx_def*, int, machine_mode,
> > > machine_mode, int)
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/optabs.cc:4637
> > > 0xc0b33a prepare_cmp_insn
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/optabs.cc:4538
> > > 0xc0f0dd emit_conditional_move(rtx_def*, rtx_comparison, rtx_def*,
> > > rtx_def*, machine_mode, int)
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/optabs.cc:5098
> > > 0x192cc7b noce_emit_cmove
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/ifcvt.cc:1777
> > > 0x193365b try_emit_cmove_seq
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/ifcvt.cc:3410
> > > 0x193365b noce_convert_multiple_sets_1
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/ifcvt.cc:3705
> > > 0x1933c71 noce_convert_multiple_sets
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/ifcvt.cc:3496
> > > 0x1938687 noce_process_if_block
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/ifcvt.cc:4045
> > > 0x1938687 noce_find_if_block
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/ifcvt.cc:4726
> > > 0x1938687 find_if_header
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/ifcvt.cc:4931
> > > 0x1938687 if_convert
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/ifcvt.cc:6078
> > > 0x1938d01 rest_of_handle_if_conversion
> > > /home/shorne/work/gnu-toolchain/gcc/gcc/ifcvt.cc:6143
> > >
> > > -Stafford
> >
> > Can you attach the .i?
>
> Sure please find attached, I can reproduce with the or1k compiler using:
>
> $HOME/work/gnu-toolchain/build-gcc/./gcc/cc1 -O2 __muldi3.i
>
> I am still debugging, but I notice when reverting the patch the compiler never
> goes to emit_move_multi_word(). I am trying to work backwards as to where it
> goes
> different, it's just taking a bit of time as I haven't debugged GCC ICE's for
> a
> while.
I made some progress on this. In openRISC we generate cstoresi4 with special
register SR_F (condition flag) bit register.
This is represented as (reg:BI 34 ?sr_f).
The RTL produced for cstoresi4 becomes something like:
// The compare
(insn 49 48 50 (set (reg:BI 34 ?sr_f)
(leu:BI (reg/v:SI 68 [ __x2D.6783 ])
(reg/v:SI 69 [ __x1D.6782 ])))
"/home/shorne/work/gnu-toolchain/gcc/libgcc/libgcc2.c":532:22 -1
(nil)
// The conditional branch
(jump_insn 50 49 0 (set (pc)
(if_then_else (ne (reg:BI 34 ?sr_f)
(const_int 0 [0]))
(label_ref 0)
(pc)))
"/home/shorne/work/gnu-toolchain/gcc/libgcc/libgcc2.c":532:22 -1
(int_list:REG_BR_PROB 536870916 (nil)))
During ce1 the try_emit_cmove_seq would try to convert (reg:BI 34 ?sr_f) to SI.
Before this patch it was done in gen_lowpart_general by
simplify_context::simplify_gen_subreg.
The simplity to subreg operation would convert:
(reg:BI 34 ?sr_f)
To:
(subreg:SI (reg:BI 34 ?sr_f) 0)
But now the call to validate_subreg is returning false and simplify_gen_subreg
returns NULL_RTX, this causes gen_lowpart_general to try to do copy_to_reg,
which fails.
I need to step away for a bit, but I would next look into why validate_subreg
is now failing to allow (reg:BI 34 ?sr_f) to be subreg'd.
-Stafford
