On Mon, May 17, 2021 at 10:55 AM Joern Rennecke <joern.renne...@embecosm.com> wrote: > > On Mon, 17 May 2021 at 08:36, Richard Biener <richard.guent...@gmail.com> > wrote: > > > > On Sun, May 16, 2021 at 8:53 PM Joern Rennecke > > <joern.renne...@embecosm.com> wrote: > > > > > > For architectures with likely spilled register classes, neither > > > register allocator is guaranteed > > > to succeed when using optimization. If you have just a few files to > > > compile, you can try > > > by hand which compiler options will succeed and still give reasonable > > > code, but for large projects, > > > hand-tweaking library / program build rules on a file-by-file basis is > > > time intensive and does not > > > scale well across different build environments and compiler versions. > > > > > > The attached patch adds a new option -fretry-compilation that allows > > > you to specify a list - or > > > lists - of options to use for a compilation retry, which is > > > implemented in the compiler driver. > > > > > > Bootstrapped on x86_64-pc-linux-gnu. > > > > Eh, no ;) But funny idea, nevertheless. > > Why no? > > lra just throws a ton of transformations at the code with no theoretical > concept that I can discern that it should - modulo bugs - succeed for > all well-formed code. It works well most of the time so I'd like to use it as > a default, but how are you supposed to compile libgcc and newlib with > a register allocator that only works most of the time? > > reload is more robust in the basic design, but it's so complex that it's > rather time-consuming to debug. The failures I had left with reload > were not spill-failures per se, but code that was considered mal-formed by > the postreload passes and it's hard to decide which one was actually wrong. > And if I debug the failures seeen with realod, will this do any good in the > long run, or will it just be changed beyond all recognition (with works for > the top five most popular processor architectures but not quite for anything > else) or plain ripped out a few years down the line?
The plan for reload is to axe it similar to CC0 support. Sooner than later, but give it's still used exclusively by a lot of target means it might take some time. > I had a proof-of-concept for the option in the target code first, but that > used > fork(2) and thus left non-POSIX hosts (even if they have a pretend POSIX > subsystem) high and dry. The logical place to implement the option to > make it portable is in the compiler driver. > I've called the option originally -mretry-regalloc / -fretry-regalloc, but > when > I got around to write the invoke.texi patch, I realized that the option can be > used more generally to work around glitches, so it's more apt to name it > -fretry-compilation . So for you it's always just -fretry-compilation -m[no-]lra? Given -m[no-]lra is a thing cycling between the two directly in RA lra/reload should be possible? Or are reload/LRA too greedy in that they ICE when having transformed half of the code already? > > Do you run into the issues > > with the first scheduling pass disabled? > > The target doesn't have anything that needs scheduling, and hence no > scheduling > description. But it also has more severe register pressures for > memory access than > ports in the FSF tree. I see. It's of course difficult for the FSF tree to cater for extremes that are not represented in its tree. I wonder what prevents you from contributing the port? > The bane of lra are memory-memory moves. Instead of using an intermediate > register, it starts by reloading the well-formed addresses and thus jacking up > the base register pressure. > > I had a patch for that, but I found it needs a bit more work. Still if that solves a lot of the issues this seems like the way to go. Richard.
