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 -- H.J.
