On Mon, May 21, 2012 at 9:33 AM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Wed, Apr 11, 2012 at 7:35 AM, Bernd Schmidt <ber...@codesourcery.com> > wrote: >> On 12/23/2011 05:31 PM, Vladimir Makarov wrote: >>> On 12/21/2011 09:09 AM, Bernd Schmidt wrote: >>>> This patch was an experiment to see if we can get the same improvement >>>> with modifications to IRA, making it more tolerant to over-aggressive >>>> scheduling. THe idea is that if an instruction sets a register A, and >>>> all its inputs are live and unmodified for the lifetime of A, then >>>> moving the instruction downwards towards its first use is going to be >>>> beneficial from a register pressure point of view. >>>> >>>> That alone, however, turns out to be too aggressive, performance drops >>>> presumably because we undo too many scheduling decisions. So, the patch >>>> detects such situations, and splits the pseudo; a new pseudo is >>>> introduced in the original setting instruction, and a copy is added >>>> before the first use. If the new pseudo does not get a hard register, it >>>> is removed again and instead the setting instruction is moved to the >>>> point of the copy. >>>> >>>> This gets up to 6.5% on 456.hmmer on the mips target I was working on; >>>> an embedded benchmark suite also seems to have a (small) geomean >>>> improvement. On x86_64, I've tested spec2k, where specint is unchanged >>>> and specfp has a tiny performance regression. All these tests were done >>>> with a gcc-4.6 based tree. >>>> >>>> Thoughts? Currently the patch feels somewhat bolted on to the side of >>>> IRA, maybe there's a nicer way to achieve this? >>>> >>> I think that is an excellent idea. I used analogous approach for >>> splitting pseudo in IRA on loop bounds even if it gets hard register >>> inside and outside loops. The copies are removed if the live ranges >>> were not spilled in reload. >>> >>> I have no problem with this patch. It is just a small change in IRA. >> >> Sounds like you're happier with the patch than I am, so who am I to argue. >> >> Here's an updated version against current trunk, with some cc0 bugfixes >> that I've since discovered to be necessary. Bootstrapped and tested (but >> not benchmarked again) on i686-linux. Ok? >> >> >> Bernd > > This caused: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53411 >
This also caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53495 -- H.J.
