https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118036
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jeff Law <l...@gcc.gnu.org>: https://gcc.gnu.org/g:509df13fbf0b3544cd39a9e0a5de11ce841bb185 commit r15-6476-g509df13fbf0b3544cd39a9e0a5de11ce841bb185 Author: Robin Dapp <rdapp....@gmail.com> Date: Mon Dec 30 23:47:53 2024 -0700 [PATCH v2] varasm: Use native_encode_rtx for constant vectors. optimize_constant_pool hashes vector masks by native_encode_rtx and merges identically hashed values in the constant pool. Afterwards the optimized values are written in output_constant_pool_2. However, native_encode_rtx and output_constant_pool_2 disagree in their encoding of vector masks: native_encode_rtx does not pad with zeroes while output_constant_pool_2 implicitly does. In RVV's shuffle-evenodd-run.c there are two masks (a) "0101" for V4BI (b) "01010101" for V8BI and that have the same representation/encoding ("1010101") in native_encode_rtx. output_constant_pool_2 uses "101" for (a) and "1010101" for (b). Now, optimize_constant_pool might happen to merge both masks using (a) as representative. Then, output_constant_pool_2 will output "1010" which is only valid for the second mask as the implicit zero padding doesn't agree with (b). (b)'s "1010101" works for both masks as a V4BI load will ignore the last four padding bits. This patch makes output_constant_pool_2 use native_encode_rtx so both functions will agree on an encoding and output the correct constant. PR target/118036 gcc/ChangeLog: * varasm.cc (output_constant_pool_2): Use native_encode_rtx for building the memory image of a const vector mask.
