Created attachment 49410 [details] reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -Og -finline-functions-called-once -fno-tree-ccp -mavx512vbmi -mavx512vl testcase.c testcase.c: In function 'foo': testcase.c:15:1: error: unrecognizable insn: 15 | } | ^ (insn 9 8 10 2 (set (reg:V16QI 84 [ _8 ]) (vec_merge:V16QI (const_vector:V16QI [ (const_int 0 [0]) repeated x16 ]) (const_vector:V16QI [ (const_int 0 [0]) repeated x16 ]) (reg:HI 90))) "testcase.c":8:17 -1 (nil)) during RTL pass: vregs testcase.c:15:1: internal compiler error: in extract_insn, at recog.c:2294 0x6ef463 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.c:108 0x6ef4e6 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /repo/gcc-trunk/gcc/rtl-error.c:116 0x6de26e extract_insn(rtx_insn*) /repo/gcc-trunk/gcc/recog.c:2294 0xce62b3 instantiate_virtual_regs_in_insn /repo/gcc-trunk/gcc/function.c:1607 0xce62b3 instantiate_virtual_regs /repo/gcc-trunk/gcc/function.c:1977 0xce62b3 execute /repo/gcc-trunk/gcc/function.c:2026 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-4031-20201019090534-g04ffed2ef29-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-4031-20201019090534-g04ffed2ef29-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20201019 (experimental) (GCC)
Started with r11-2577-g229752afe3156a3990dacaedb94c76846cebf132
Could be fixed by diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c index e6f8b314f18..19c12df4401 100644 --- a/gcc/config/i386/i386-expand.c +++ b/gcc/config/i386/i386-expand.c @@ -3525,6 +3525,14 @@ ix86_expand_sse_movcc (rtx dest, rtx cmp, rtx op_true, rtx op_false) machine_mode mode = GET_MODE (dest); machine_mode cmpmode = GET_MODE (cmp); + /* Simplify this trivial compare, avoid ICE error in pr97506. */ + if (rtx_equal_p (op_true, op_false)) + { + emit_move_insn (dest, op_true); + return; + } + /* In AVX512F the result of comparison is an integer mask. */ bool maskcmp = mode != cmpmode && ix86_valid_mask_cmp_mode (mode); But shouldn't middle end also simplify such trivial VCOND_EXPR. _4 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; _6 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; _8 = .VCONDU (_6, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, _4, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, 113);
Targets shouldn't ICE on unsimplified stuff - the testcase explicitely disables constant propagation so I guess we get what was asked for.
Yeah. On the other side, they don't need to try hard to optimize it because normally it should be simplified already. So, e.g. the above patch is fine if it works, but it would be also fine to force_reg one of the operands into register, etc.
(In reply to Jakub Jelinek from comment #4) > Yeah. On the other side, they don't need to try hard to optimize it because > normally it should be simplified already. So, e.g. the above patch is fine > if it works, but it would be also fine to force_reg one of the operands into > register, etc. Yes, something like, both patches work for this bug. --- @@ -3552,7 +3545,8 @@ ix86_expand_sse_movcc (rtx dest, rtx cmp, rtx op_true, rtx op_false) /* Optimize for mask zero. */ op_true = (op_true != CONST0_RTX (mode) ? force_reg (mode, op_true) : op_true); - op_false = (op_false != CONST0_RTX (mode) + /* Avoid ICE in PR97506 when both op_true and op_false are const0_rtx. */ + op_false = (op_false != CONST0_RTX (mode) || op_true == CONST0_RTX (mode) ? force_reg (mode, op_false) : op_false); if (op_true == CONST0_RTX (mode)) ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>: https://gcc.gnu.org/g:9b5d50b7c6e34267b40bdeb4c145e9132d83762d commit r11-4184-g9b5d50b7c6e34267b40bdeb4c145e9132d83762d Author: liuhongt <hongtao.liu@intel.com> Date: Wed Oct 21 13:05:16 2020 +0800 Simplify trivial VEC_COND_EXPR in expander. gcc/ChangeLog: PR target/97506 * config/i386/i386-expand.c (ix86_expand_sse_movcc): Move op_true to dest directly when op_true equals op_false. gcc/testsuite/ChangeLog: PR target/97506 * gcc.target/i386/pr97506.c: New test.
Should i backport to GCC10? Although it's exposed in GCC11, but it's still a potential bug in GCC10.
Yes, looks safe to me.
The releases/gcc-10 branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>: https://gcc.gnu.org/g:36ee59a2640712a6e24d9e27290bc5ebbef39709 commit r10-8933-g36ee59a2640712a6e24d9e27290bc5ebbef39709 Author: liuhongt <hongtao.liu@intel.com> Date: Wed Oct 21 13:05:16 2020 +0800 Simplify trivial VEC_COND_EXPR in expander. gcc/ChangeLog: PR target/97506 * config/i386/i386-expand.c (ix86_expand_sse_movcc): Move op_true to dest directly when op_true equals op_false. gcc/testsuite/ChangeLog: PR target/97506 * gcc.target/i386/pr97506.c: New test.
Fixed.