> On 17 Jun 2026, at 22:47, Vladimir Makarov <[email protected]> wrote: > > > On 6/17/26 11:07 AM, [email protected] wrote: >> From: Kyrylo Tkachov <[email protected]> >> >> PR target/105116 is an aarch64 ICE in lra_split_hard_reg_for ("unable to >> find a register to spill"). A wide vector value (OImode, a pair of Q >> registers) is pinned to FP registers via asm register variables and an >> operation with no Advanced SIMD form (an integer vector divide or modulo) is >> scalarised by vector lowering. The scalar pieces read non-lowpart scalar >> subregs of the OImode register, e.g. (subreg:DI (reg:OI v2) 8), the high 64 >> bits of the first Q register. >> >> Such a subreg is not representable as a hard register (subreg_get_info >> returns representable_p == false), but the hard-register branch of >> simplify_operand_subreg only called alter_subreg, which resolves it to the >> wrong part of the register. For GENERAL_REGS uses, curr_insn_transform then >> tried to reload the whole OImode inner register into GENERAL_REGS, which is >> impossible (aarch64_hard_regno_mode_ok is false for OImode in GENERAL_REGS) >> and gave the ICE; for FP-context uses the bad subreg survived to final and >> silently read the wrong bytes (a latent wrong-code bug). >> >> Handle this in simplify_operand_subreg: when a narrowing subreg of a hard >> register is not representable, reload the inner register through memory >> (NO_REGS) so that the correct bytes are accessed, mirroring the existing >> handling for pseudos. The frame, arg and stack pointers are left alone, as >> simplify_subreg_regno can reject them merely because reload is not finished. >> This only affects the already non-representable case; representable subregs >> are unchanged. >> >> Bootstrapped and tested on aarch64-none-linux-gnu and x86_64-linux. >> >> Ok for trunk? > Yes. I found no issues in the patch. Thank you for the patch and working on > this PR.
Thank you. This ICE also occurs on the 16, 15 and 14 branches. The patch applies cleanly and I’m testing it on aarch64. Is it okay to back port to the branches as well if testing is clean? Thanks, Kyrill >> Signed-off-by: Kyrylo Tkachov <[email protected]> >> >> gcc/ChangeLog: >> >> PR target/105116 >> * lra-constraints.cc (simplify_operand_subreg): Reload a >> non-representable narrowing subreg of a hard register through >> memory instead of resolving it lossily. >> >> gcc/testsuite/ChangeLog: >> >> PR target/105116 >> * gcc.target/aarch64/sve/pr105116.c: New test. >> * gcc.target/aarch64/sve/pr105116-run.c: New test.
