https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66591
--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> --- I have started working on the R0 issue... An R0-pre-allocating pass might potentially break down again when reload/LRA tries to emit mem access insns, which have an R0 constraint. Although the pre-allocating would probably relax the issue, it will be not be bullet proof. What I'm trying now is to mark R0 as a hardreg and exclude it from the normal register allocation process. This doesn't mean that it will not be used at all. E.g. the return values still work OK with that. To avoid many changes in the code I'm making the 'z' register constraint conditional. Initially it's disabled and allows all GP regs (i.e. it's like 'r' constraint). Then, after regular RA,reload/LRA the 'z' constraint is enabled and a special SH pass is ran to fix up missed 'z' constraints. Of course this will have some expected regressions because effectively it has one register less during normal RA. However, I believe the post-alloc strategy will be more robust than pre-alloc, as it will also deal with stack-frame access insns generated by reload/LRA. To compensate the regressions, an additional R0 pre-alloc pass can be done later on.
