On Tue, 2026-06-23 at 09:59 +0200, Richard Biener wrote: > On Tue, 23 Jun 2026, Oleg Endo wrote: > > > Hi all, > > > > On Tue, 2026-03-03 at 08:07 -0700, Jeffrey Law wrote: > > > On 3/2/2026 10:11 PM, Oleg Endo wrote: > > > > > > > > > > > > > > > > Please let me know what you find out and your thoughts on this. > > > > > Will do. It's in my gcc-17 queue :-) > > > > > > I'd like to bring this issue up again. For reference, the PR is > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117182 > > > > and the discussion stopped here > > https://gcc.gnu.org/pipermail/gcc-patches/2026-March/710309.html > > > > > > According to my understanding, we came to the rough conclusion: > > > > - To fix it "the right way", LRA needs to validate its insn changes against > > mode-switching states > > > > - For that some mode-switching API extension will be required > > > > - As of today nothing after the mode-switching pass validates insn changes > > w.r.t. the implicit mode switching states. It just happens to blow up with > > LRA first because it changes/inserts move insns, which are subject to mode > > switching on SH. > > To me this sounds like trying to move mode switching way later might > be more feasible as even if you fix LRA any other pass might perform > similar errorneous transforms?
Yes, that is correct. It's been a silent issue for everything that follows mode-switching. If the can is kicked further down the road (insert mode- switching at a later point) we run into the issue that the code to implement the mode-switches also requires free registers and can break branch displacement constraints and so on. I also don't know what the consequences would be for other backends. > > > So this makes it look more like a general infrastructure issue rather than > > target issue to me. The failure mode is silent wrong-code in floating-point > > heavy code. It shows up only at runtime, is not caught by bootstrap and is > > a borderline heisenbug as it highly depends on surrounding code and > > optimizations, which makes it very easy to declare "fixed" when > > it isn't. > > > > Because of that, I firmly believe this should be addressed first before > > landing the final SH LRA conversion patches. > > > > My concern is that the folks still building and running real software on > > real SH4 hardware rarely file bugs upstream. When the toolchain miscompiles > > their code, that often stays in the inner circles, the new compiler version > > is declared to be "fundamentally broken", they stop updating, and drift > > toward out-of-tree alternatives. So a miscompiling-but-LRA-clean backend > > wouldn't show up as open PRs; it would just silently erode the remaining > > user base while looking fine on the surface. > > > > The LRA conversion work itself is essentially ready. What's currently > > missing is the fix for the mode-switching/LRA interaction, and that's beyond > > what I can resource myself. > > Without knowing anything on the technical detail (esp. not about > mode switching and its implementation), and without being able to > make the promise that reload will really be gone for GCC 17 (but I > hope so), in the end you'll still face the problem that without > reload you either have to use LRA or have no working SH port. > > I'd also say that the earlier you switch to LRA the more coverage > you'll get - there might be other unknown issues. But I also get > what you say above, but this sounds like communicating the fact > to the SH user community is what's required - there's nothing we > can do here. I've been in touch with the community and they seem to be aware. Folks have been helping test riding LRA-enabled SH-GCC on and off for a few years now, but with the rejected workaround patch. Overall it seems there are few performance regressions but it also resolves some of the longstanding R0_REGS spill-failure ICEs. Even Adrian himself has been using the same patchset to package GCC for SH4 Debian. Best regards, Oleg Endo
