On Fri, 2 May 2025, Maciej W. Rozycki wrote: > On Fri, 2 May 2025, Richard Biener wrote: > > > I'd appreciate target maintainers of targets with a -mlra to > > enable LRA by default and unconditionally (aka, remove -mlra) > > themselves. Eventually that work will be done in a more-or-less > > unchecked way later. > > I do appreciate the desire to remove legacy reload, but regrettably at > this time I cannot guarantee I'll find the resources to fix the backends I > care about in the GCC 16 timeframe: > > - A few years ago I updated the VAX backend to at least complete building > a cross-compiler successfully, but there are still ICE regressions. > Also code quality is awful as suddenly the backend has lost the ability > to make use of most of the address modes, as if the CPU only had the > most basic RISC-style base+offset address mode. I don't consider it a > showstopper though. > > However an outstanding problem with the backend has been that it hasn't > implemented an exception unwinder. Needless to say that makes the C++ > frontend unusuable for most cases (VAX-host GCC itself being a notable > exception), so any time I find for VAX/GCC effort I'll have to dedicate > instead to this issue on a priority basis. It's tough and I'm still not > sure if DWARF is capable enough (and then at what initial version of the > standard) to express the semantics required let alone how much extra > code will be required on the libgcc side, so it won't be quick. Scarce > resources on exception unwinder internals don't help even though the > principle of operation appears straightforward at the high level. > > - I have only learnt last year that the Alpha backend also needs some work > here and it appears that it relies on a hack or a bunch within reload to > propagate alignment information required for non-BWX targets to produce > correct code. I haven't been able to investigate it further, but it > seems it may require considerable effort to solve and as it stands the > backend doesn't build if switched to LRA. And then last year's sudden > removal of non-BWX support from the Linux kernel has consumed my already > limited time for work on a solution to bring it back instead (with more > effort still required, also as a matter of priority). > > All in all I do keep the switch to LRA in mind and maybe I'll be able to > move forward in the GCC 16 development cycle after all, but all I can do > is entirely in my free time and that seems to be very limited recently and > plagued with emergencies to handle.
I appreciate your work on those targets. It seems that both are in a state where basic development and testing _of GCC_ can be done when LRA is enabled? That means users can stick to GCC 15 which will be supported for the next 3 years and avoid newer versions when the issues affect them. There's always the hope that other interested parties contribute fixes to GCC 16 and on to recover the loss taken by removing reload, esp. if the ports itself do not end up 100% broken. Richard.
