https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Alex Coplan <acop...@gcc.gnu.org>: https://gcc.gnu.org/g:150a829accd76ddd73c20628774cb0781f6e8bfe commit r11-7764-g150a829accd76ddd73c20628774cb0781f6e8bfe Author: Alex Coplan <alex.cop...@arm.com> Date: Mon Mar 22 14:43:15 2021 +0000 arm: Fix MVE ICEs with vector moves and -mpure-code [PR97252] This fixes around 500 ICEs in the testsuite which can be seen when testing with -march=armv8.1-m.main+mve -mfloat-abi=hard -mpure-code (leaving the testsuite free of ICEs in this configuration). All of the ICEs are in arm_print_operand (which is expecting a mem and gets another rtx, e.g. a const_vector) when running the output code for *mve_mov<mode> in alternative 4. The issue is that MVE vector moves were relying on the arm_reorg pass to move constant vectors that we can't easily synthesize to the literal pool. This doesn't work for -mpure-code where the literal pool is disabled. LLVM puts these in .rodata: I've chosen to do the same here. With this change, for -mpure-code, we no longer want to allow a constant on the RHS of a vector load in RA. To achieve this, I added a new constraint which matches constants only if the literal pool is available. gcc/ChangeLog: PR target/97252 * config/arm/arm-protos.h (neon_make_constant): Add generate argument to guard emitting insns, default to true. * config/arm/arm.c (arm_legitimate_constant_p_1): Reject CONST_VECTORs which neon_make_constant can't handle. (neon_vdup_constant): Add generate argument, avoid emitting insns if it's not set. (neon_make_constant): Plumb new generate argument through. * config/arm/constraints.md (Ui): New. Use it... * config/arm/mve.md (*mve_mov<mode>): ... here. * config/arm/vec-common.md (movv8hf): Use neon_make_constant to synthesize constants.
