Jeffrey Law <[email protected]> writes: > On 7/7/2026 4:47 AM, Mikael Pettersson wrote: >> Since gcc-15 combine can produce moves from a PRE_DEC source to a >> destination that uses the same register, causing wrong code on m68k. >> In particular the glibc build is broken. This adjusts the m68k >> backend to reject such moves: >> >> move.l -(%a0),(%a0,%d0.l) >> >> and instead emit: >> >> lea (%a0,%d0.l),%a1 >> move.l -(%a0),(%a1) >> >> Bootstrapped and regression tested on m68k-linux-gnu, no regressions. >> >> Ok for trunk? And maybe gcc-16/15 after a week? >> >> gcc/ >> >> 2026-07-07 Mikael Pettersson <[email protected]> >> >> PR rtl-optimization/123853 >> * config/m68k/m68k-protos.h (check_move_simode): Declare. >> * config/m68k/m68k.cc (check_move_simode): New, reject moves from >> a pre-dec source mem whose reg occurs in the destination address. >> * config/m68k/m68k.md (*movsi_m68k): Add check_move_simode to >> condition. >> (*movsi_m68k2): Likewise. > I think the new dynamic register filters are going to be the way to > handle this. The core issue is those additional uses of a > auto-incremented register, which requires looking at two operands to > determine if the insn matches its constraints. This patch just papers > over the problem and it likely triggers elsewhere in the port with > some effort. > > My recommendation is to wait until Pan Li's work to utilize the > dynamic register filtering lands in the RISC-V port across the board > and gets a time to shake out any additional LRA gotchas, then use it > on the m68k, h8 and pdp11 which all have the same core problem.
For the PR, we'd love something backportable though, and having a patch which was never on trunk isn't ideal, though it is quite targeted.. > > Jeff
signature.asc
Description: PGP signature
