On Mon, Jun 09, 2025 at 04:42:49PM +0100, Richard Sandiford wrote: > Stafford Horne <sho...@gmail.com> writes: > > 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 <sho...@gmail.com> 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'm not sure how the current openRISC model is supposed to work. > It seems that SR[F] only allows BImode, but there is no movbi, > and thus no way of moving anything to or from the flags in BImode. > Thus the only permitted accesses to SR[F] are the hard-coded uses > in the .md patterns, all of which need to be :BI rather than :SI. > I'm not sure in those circumstances how cstoresi4 (which expects > everything in SImode) can apply to SR[F] results. Or is the point > that it's not supposed to?
Yes, that's right. SR[F] is only BI mode, and it acts just as a intermediary for the RTL to tie the comparison operations to the branch/cmove ops. So, I have doubts that my patch to re-allow subregs is correct. The instrctuions that use SR[F] are, 'l.cmov rd,ra,rb' (rd = SR[F] ? ra : rb) and conditional branch instructions (l.bf / l.bnf). I will see if there is a way to steer the ce1 pass away from attempting to subreg/move the SR[F] condition and do a possible 'l.cmov'. -Stafford
