On 03/18/2014 04:59 AM, Jakub Jelinek wrote: > On Mon, Mar 17, 2014 at 03:24:14PM -0400, Vladimir Makarov wrote: >> It is complicated. There is no guarantee that it is used only for >> addresses. I need some time to think how to fix it. >> >> Meanwhile, you *should* commit the patch into the trunk because it >> solves the real problem. And I can work from this to make changes >> that the new pattern is only used for addresses. >> >> The patch is absolutely safe for all targets but s390. There is >> still a tiny possibility that it might result in some problems for >> s390 (now I see only one situation when a pseudo in a subreg >> changed by equiv plus expr needs a reload). In any case your patch >> solves real numerous failures and can be used as a base for further >> work. >> >> Thanks for working on this problem, Andreas. Sorry that I missed >> the PR60501. > > BTW, does LRA require that CC isn't clobbered when it uses > emit_add2_insn? I don't see how it can be guaranteed > (except perhaps on i?86/x86_64 and maybe a few other targets).
At least in pre-LRA days one *had* to have such an addition, or alternately you had to leave compare+use as a single insn pattern until post-reload splitting. I assume that's really unchanged with LRA... > emit_add3_insn should be ok (even on s390*?) because recog_memoized > should (I think) never add clobbers (it calls recog with 0 > as last argument), but gen_add2_insn is a normall add<Pmode>3 insn that > on many targets clobbers CC. Sure, but s390 has no choice but to implement the clobber-less add with the LOAD ADDRESS instruction. Which is perfectly safe for 64-bit, but for 32-bit will in fact crop that 31st bit. Which is perfectly safe so long as we never want to do addition except on pointers. Which brings us back to Vlad's point about REG_EQUIV being a potential hazzard. I agree with Vlad that we're better off with Andreas' patch than without, since computing addresses is going to be 99% of what reload/LRA needs to do. I also agree with Eric that some better commentary would be nice. r~
