> On Jul 7, 2026, at 10:21 AM, Jeffrey Law <[email protected]> wrote:
>
>
>
> On 7/7/2026 7:31 AM, Paul Koning wrote:
>>
>>> On Jul 7, 2026, at 8:02 AM, Jeffrey Law <[email protected]>
>>> wrote:
>>>
>>>
>>>
>>> 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.
>> I dealt with it in pdp11.md in a different way, using a string of
>> constraints to express this. It seems to work but it's rather cumbersome.
> Yea. I took your idea and implemented it for the H8. As you note, it's
> cumbersome and as the number of registers you have to deal with grows, it
> gets worse. When we started looking at the overlap problems with vector on
> RISC-V it was pretty clear that this approach wouldn't be maintainable. The
> design of the dynamic filters was mean to handle the RISC-V case, but
> handling the m68k, h8 and pdp11 cases was always in the back of my mind.
That sounds great. Is there a pointer to a description of this approach? I
may want to switch to that, it sure would make things more readable.
paul
