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.
