On Fri, Oct 26, 2012 at 2:54 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Fri, Oct 26, 2012 at 8:30 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> On Thu, Oct 25, 2012 at 11:21 PM, Jakub Jelinek <ja...@redhat.com> wrote: >>> On Thu, Oct 25, 2012 at 11:15:06PM -0700, H.J. Lu wrote: >>>> Should there be a -fno-ira option before reload pass is >>>> removed? It will be useful to investiage IRA regressions. >>> >>> You mean -fno-lra, and s/IRA/LRA/, right? I think the reason for no >> >> Yes, I meant -fno-lra. >> >>> compiler switch is that while returning false from ix86_lra_p () >>> likely works right now, -fno-lra mode would be yet another >>> thing to support. So, for investigations just return false from ix86_lra_p, >>> similarly for benchmarking, but as it needs compiler source changes, it is >>> obvious that with old reload everybody is on their own if it breaks >>> for targets that switched to LRA. >>> >> >> I'd like to compare glibc code quality on x32, x86-64 and ia32 >> with and without LRA. We don't even need to document -fno-lra >> or we can make it -mno-lra as x86 undocumented switch. I >> expect -fno-lra/-mno-lra will only be useful in a short period >> of time. > > You can always compare to the revision before LRA merged. My understanding > is that -fno-lra is not easily possible as backends change in non-trivial > ways once they go the LRA way. Thus you'd not compare what you want > to compare. >
I created hjl/lra git branch and added -mno-lra to x86 backend. For now, one can use it to compare LRA vs reload code quality on x86.. -- H.J.
