https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #322 from Oleg Endo <olegendo at gcc dot gnu.org> --- (In reply to Kazumoto Kojima from comment #316) > (In reply to Oleg Endo from comment #314) > > Can you please add the patch to your github branch? > > I would like to ask some Dreamcast folks to try and test the GCC LRA branch > > with some bigger real-world software. For that we need to have a "known > > good state" of a branch on github. > > I've pushed the sfunc patch with lengthy sfunc patterns using > hard_reg_r[456] + the patch in c#312 on the top of > > [59157] a revised patch to movsf issue which splits movesf_ie_ra > [59158] a revised patch to QIHI extend/move > [59153] Alex's patch works magically for call_pcrel* issue. > > as sh-lra-take3 branch of https://github.com/kazkojima/gcc.git. Hope this > helps. Thanks! I've also created a branch with your patches here: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/sh-lra I've retouched the commits a little bit here and there, mainly in the comments and commit messages. If you have more patches or make a new branch, I will gradually merge them over and try to keep the devel/sh-lra branch in a useful state. With the current state, some open issues like PR 112115 are resolved. But others like PR 115949 or PR 113193 still remain. Although those cases have been also problematic before LRA as well. I might be wrong, but I've got this feeling that whenever LRA hits the "reload limit" it's an indicator that something is running in circles in the move-insn pattern definitions. I've noticed one thing. The patch 'SH: pin input args to hard-regs via predicates for sfuncs' skips the change for the patterns 'udivsi3_i4_int' and 'block_move_real_i4'. Is this intentional or by accident?
