[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" <gcc-bugzilla@gcc.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.