https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #324 from Kazumoto Kojima <kkojima at gcc dot gnu.org> --- (In reply to Oleg Endo from comment #322) > 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. Thanks! > 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. You are right. I have not seen any other cases yet. > 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? It's intentional. Those sfunc's don't clobber r4, r5 and r6. sdivsi3_* and other are in the similar situation.
