https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #262 from Kazumoto Kojima <kkojima at gcc dot gnu.org> --- (In reply to Oleg Endo from comment #261) > I'm a little concerned because of PR 115949. It shows that there are some > fundamental issues with move patterns like `movsi_ie`. It seems real-world > code is very easy to hit that problem. > > I'm thinking to remove the FP alternatives from 'movsi_ie' and similarly, > remove the GP alternatives from 'movsf_ie'. Kaz, since you've been looking > in similar places recently ( e.g. > https://github.com/kazkojima/gcc/commit/ > ed9236ca72bda40f4f68ce6ff0cea7a47d710836 ), what's your opinion on that? movsf_ie_ra was a workaround for the issue that LRA tends to allocate memory displacemant for the scratch register. I'm not sure that is related directly with pr115949. I've found many issues even with movsf_ie_ra by checking the result of "make check-gcc RUNTESTFLAGS="--target_board=unix/-m4/-mlra" on qemu. After all, the constraints in match_scratch of movsf_ie_ra will make problems on SH. I'm trying to remove them with splitting movsf_ie_ra into several patterns and some of them use more restricted predicates. general_mov{src,dst}_operand has some codes for that LRA behavior, but perhaps more ristricted predicates and specific patterns will be safer as you pointed out.
