https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125390
--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Robin Dapp <[email protected]>: https://gcc.gnu.org/g:d5ac76d8da87236519d4ee9144ae993302814981 commit r17-5483-gd5ac76d8da87236519d4ee9144ae993302814981 Author: Robin Dapp <[email protected]> Date: Thu Oct 22 11:56:28 2026 +0200 expand: Improve tuple-extraction handling. After the REGMODE_NATURAL_SIZE changes have landed, this is another small improvement for PR125390 which also fixes aarch64's struct_3_256.c regression. Originally a riscv-specific issue and ICE, I noticed poor codegen when we extract values from a tuple type. In the optimized dump we have: vect_array.9 = .MASK_LEN_LOAD_LANES (&c, 32B, { -1, -1, -1, -1 }, _44(D), 4, 0); _48 = BIT_FIELD_REF <vect_array.9[0], 32, 96>; _50 = BIT_FIELD_REF <vect_array.9[1], 32, 96>; f_13 = _48 ^ _50; a = f_13; and _48 as well as _50 spill to memory instead of extracting directly. We end up with (subreg:RVVMF2SI (reg:RVVMF2x2SI 138 [ vect_array.9 ]) 0) which, as we pun the with a large integer mode, involves OImode that we cannot "move". We might be able to work around that in the target in unintuitive ways :) and we could also offer vec_extract for all tuple modes. However, I figured it would be much easier if expand already handled the tuple -> vector part for us so just a vector extract is left for the target to do. The patch adds multi-vector-reg -> vector functionality as a separate function and also moves vector-vector, as well as vector-element extract into new functions. PR middle-end/125390 gcc/ChangeLog: * expmed.cc (extract_bit_field_1): Call new functions. (extract_vector_from_vector): New function. (extract_element_from_vector): Likewise. (extract_vector_from_multireg): Likewise. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr125390.c: Adjust test expectation.
