[Bug target/112943] New: ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2 -march=westmere -mapxf

[Bug target/112943] New: ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2 -march=westmere -mapxf

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112943

            Bug ID: 112943
           Summary: ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2
                    -march=westmere -mapxf
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-pc-linux-gnu

Created attachment 56844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56844&action=edit
auto-reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -march=westmere -mapxf testcase.c
testcase.c: In function 'foo0':
testcase.c:26:22: warning: integer constant is so large that it is unsigned
   26 |   __int128 u128_2 = (9223372036854775808 << 4) * foo0_u8_0,
      |                      ^~~~~~~~~~~~~~~~~~~
during RTL pass: split2
testcase.c:59:1: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1176
   59 | }
      | ^
0x74ec9a gen_reg_rtx(machine_mode)
        /repo/gcc-trunk/gcc/emit-rtl.cc:1176
0x1088ef5 force_reg(machine_mode, rtx_def*)
        /repo/gcc-trunk/gcc/explow.cc:682
0x19b968f ix86_fixup_binary_operands(rtx_code, machine_mode, rtx_def**, bool)
        /repo/gcc-trunk/gcc/config/i386/i386-expand.cc:1311
0x19b9723 ix86_expand_binary_operator(rtx_code, machine_mode, rtx_def**, bool)
        /repo/gcc-trunk/gcc/config/i386/i386-expand.cc:1346
0x1e467cf gen_ashldi3(rtx_def*, rtx_def*, rtx_def*)
        /repo/gcc-trunk/gcc/config/i386/i386.md:14311
0x1e467cf gen_split_536(rtx_insn*, rtx_def**)
        /repo/gcc-trunk/gcc/config/i386/i386.md:14503
0x2523dd5 split_insns(rtx_def*, rtx_insn*)
        /repo/gcc-trunk/gcc/config/i386/i386.md:19293
0x10720da try_split(rtx_def*, rtx_insn*, int)
        /repo/gcc-trunk/gcc/emit-rtl.cc:3800
0x1438518 split_insn
        /repo/gcc-trunk/gcc/recog.cc:3401
0x143f3b5 split_all_insns()
        /repo/gcc-trunk/gcc/recog.cc:3505
0x143f4d8 execute
        /repo/gcc-trunk/gcc/recog.cc:4429
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
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-r14-6356-20231209102837-g36be2a0e91c-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.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
--disable-bootstrap --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-r14-6356-20231209102837-g36be2a0e91c-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231209 (experimental) (GCC)

[Bug target/112943] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2 -march=westmere -mapxf

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112943

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crazylht at gmail dot com,
                   |                            |jakub at gcc dot gnu.org
           Priority|P3                          |P1
            Summary|ICE: in gen_reg_rtx, at     |[14 Regression] ICE: in
                   |emit-rtl.cc:1176 with -O2   |gen_reg_rtx, at
                   |-march=westmere -mapxf      |emit-rtl.cc:1176 with -O2
                   |                            |-march=westmere -mapxf
   Target Milestone|---                         |14.0

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Why does ix86_expand_binary_operator have the use_ndd argument at all? 
Shouldn't it always act as if the argument is TARGET_APX_NDD?
Or, any particular reason why it isn't done in ashl<mode>3 (but in other
shifts/rotates)?
The ICE is because the
14500         if (!op_equal_p && !TARGET_APX_NDD)
14501           emit_move_insn (operands[3], operands[1]);
14502         rtx op_tmp = TARGET_APX_NDD ? operands[1] : operands[3];
14503         emit_insn (gen_ashl<mode>3 (operands[3], op_tmp, GEN_INT
(bits)));
splitter uses gen_ashl<mode>3 expander post-reload, and due to
ix86_expand_binary_operator not being called with TARGET_APX_NDD, it attempts
to force the MEM operand into a REG, which needs a pseudo.
*ashl<mode>3_1 pattern certainly uses TARGET_APX_NDD in the
ix86_binary_operator_ok call.

[Bug target/112943] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2 -march=westmere -mapxf

[wwwhhhyyy333 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112943

Hongyu Wang <wwwhhhyyy333 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wwwhhhyyy333 at gmail dot com

--- Comment #2 from Hongyu Wang <wwwhhhyyy333 at gmail dot com> ---
Sorry for introducing this, a patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640174.html

[Bug target/112943] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2 -march=westmere -mapxf

[liuhongt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112943

Hongtao Liu <liuhongt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liuhongt at gcc dot gnu.org

--- Comment #3 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> Why does ix86_expand_binary_operator have the use_ndd argument at all? 
> Shouldn't it always act as if the argument is TARGET_APX_NDD?
> Or, any particular reason why it isn't done in ashl<mode>3 (but in other
> shifts/rotates)?
By the time we support apx_ndd, the use_ndd is introduced to enable ndd pattern
by pattern so that avoid other patterns crash, and now that we've completed the
ndd patch, I think we can try to remove it. We need to make sure that there is
no pattern under TARGET_APX_NDD but force a call to ix86_expand_binary_operator
with use_ndd as false.

[Bug target/112943] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2 -march=westmere -mapxf

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112943

--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Hongyu Wang <hongyuw@gcc.gnu.org>:

https://gcc.gnu.org/g:07dcb39e08aa52f166e8d74420364757002ad756

commit r14-6445-g07dcb39e08aa52f166e8d74420364757002ad756
Author: Hongyu Wang <hongyu.wang@intel.com>
Date:   Mon Dec 11 19:30:42 2023 +0800

    i386: Fix missed APX_NDD check for shift/rotate expanders [PR 112943]

    The ashl/lshr/ashr expanders calls ix86_expand_binary_operator, while
    they will be called for some post-reload split, and TARGET_APX_NDD is
    required for these calls to avoid force-load to memory at postreload
    stage.

    gcc/ChangeLog:

            PR target/112943
            * config/i386/i386.md (ashl<mode>3): Add TARGET_APX_NDD to
            ix86_expand_binary_operator call.
            (<insn><mode>3): Likewise for rshift.
            (<insn>di3): Likewise for DImode rotate.
            (<insn><mode>3): Likewise for SWI124 rotate.

    gcc/testsuite/ChangeLog:

            PR target/112943
            * gcc.target/i386/pr112943.c: New test.

[Bug target/112943] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2 -march=westmere -mapxf

[hongyuw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112943

Hongyu Wang <hongyuw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #5 from Hongyu Wang <hongyuw at gcc dot gnu.org> ---
Fixed on trunk.

[Bug target/112943] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2 -march=westmere -mapxf

[hongyuw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112943

--- Comment #6 from Hongyu Wang <hongyuw at gcc dot gnu.org> ---
(In reply to Hongtao Liu from comment #3)
> (In reply to Jakub Jelinek from comment #1)
> > Why does ix86_expand_binary_operator have the use_ndd argument at all? 
> > Shouldn't it always act as if the argument is TARGET_APX_NDD?
> > Or, any particular reason why it isn't done in ashl<mode>3 (but in other
> > shifts/rotates)?
> By the time we support apx_ndd, the use_ndd is introduced to enable ndd
> pattern by pattern so that avoid other patterns crash, and now that we've
> completed the ndd patch, I think we can try to remove it. We need to make
> sure that there is no pattern under TARGET_APX_NDD but force a call to
> ix86_expand_binary_operator with use_ndd as false.

The ix86_expand_binary_operator and other binary fixup stuffs are not only
applied to legacy insns, they are also be used in sse/mmx patterns. If we drop
the parameter we need to maintain those vector patterns that could potential
calls the fixup functions at post-reload stage. So from design perspective, it
is better to just involve insns related to NDD, do not mess up with vector
insns.