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.
