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? 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 . > 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. 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.
