On Tue, Jun 02, 2026 at 01:03:05PM -0400, Vladimir Makarov wrote: > > Bootstrapped and regtested on > > - aarch64-unknown-linux-gnu > > - powerpc64le-unknown-linux-gnu > > - s390x-ibm-linux-gnu > > - x86_64-pc-linux-gnu > > Ok for mainline? > > Yes with minor changes mentioned below. You can address mem subreg operand > (it is just a missed optimization opportunity) in next patch if you want.
I've incorporated the changes and pushed as r17-1514-g5c8ec67c31d. With this version the decision whether to do the optimization or not is done in reload_section_anchor_p, i.e., it is ripped out of curr_insn_transform where the surrounding block already checks for MEM_P if (goal_alt_matched[i][0] == -1 && goal_alt_offmemok[i] && MEM_P (op)) I'd included the redundant MEM_P guard in reload_section_anchor_p for documentation purposes and to make it more robust in case someone uses the function in a different context in the future. Therefore, if I wanted to deal with subreg(mem), too, I would have to change the surrounding condition and make sure that the inner cases work with subreg(mem). I ran bootstrap+regtest on x86_64 and s390x but couldn't find a single hit for the surrounding context if (goal_alt_matched[i][0] == -1 && goal_alt_offmemok[i] && SUBREG_P (op) && MEM_P (SUBREG_REG (op))) Since I don't have a test for this, I will leave this as is for the moment. Aren't subreg(mem) considered unwanted nowadays? Thanks for your review! Cheers, Stefan
