On Mon, May 17, 2021 at 5:33 PM Joern Rennecke <joern.renne...@embecosm.com> wrote: > > On Mon, 17 May 2021 at 11:59, Richard Biener <richard.guent...@gmail.com> > wrote: > > > 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. > > > 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? > > Even if that were possible, it wouldn't solve the problem. When I try > compiling > newlib without -fretry-compilation, it's falling over first for > libc/time/strftime.c . > With lra, lra finishes, but it ignores an earlyclobber constraint, so > reload_cse_simplify_operands ICEs. With reload, you get a spill failure. > I've tried various options, but only -O0 seems to work. Compiling strftime > with > -O0 is not really an issue because the target is too deeply embedded to hope > to link something that uses strftime. But identifyig all the files > that can't be > compiled with optimization and treating them differently is a problem if it > has > to be done by hand. > > > Or are reload/LRA too greedy in that they ICE when having transformed half > > of the code already? > > Both of them do a lot of transformations before they ICE. Or they don't even > ICE themselves, but leave behind invalid rtl that a later pass catches. > > Even if we fixed both passes so that they could roll back everything > (which I think would be a lot harder for lra; reload can already roll > back a lot), > what's the point if you axe reload soon after? > > > 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? > > I can neither confirm nor deny that I can't contribute the port. > > > Still if that solves a lot of the issues this seems like the way to go. > > It has merit in it's own right, but it can't fix all the ICEs, and thus > doesn't > make building libraries manageable.
But then it's a sub-par quality port (whoever is to blame here), working around this way "officially" doesn't sound like a good thing. So I suppose this plumbing as to stay private to your port. Richard.
