On Mon, Nov 19, 2012 at 6:25 PM, Michael Meissner <meiss...@linux.vnet.ibm.com> wrote: > I am working on support for a future processor, and I noticed that when I did > the power7 work initially in 2009, that I ordered the DF moves so that the VSX > moves came before traditional floating point moves. > > If reload needs to reload a floating point register, it will match first on > the > VSX instructions and generate LXSDX or STXSDX instead of the traditional > LFD/LFDX and STFD/STFDX instructions. Because the LXSDX/STXSDX instructions > are only REG+REG, reload needs to generate the stack offset in a GPR and use > this. Note, for normal loads/stores, the register allocator will see if there > are other options, and eventually match against the traditional floating point > load and store. Reload however, seems to stop as soon as it finds an > appropriate instruction. > > The following patch reorders the movdf patterns so that first the traditional > floating point registers are considered, then the VSX registers, and finally > the general purpose registers. I have bootstrapped the compiler with these > changes, and had no regressions in the testsuite. > > I also ran the spec 2006 benchmark suite with/without these patches (using > subversion id 193503 as the base). There were no slow downs that were outside > of the normal range that I consider to be noise level (2%). The 447.dealII > benchmark sped up by 14% (456.hmmer and 471.omnetpp sped up by 2%). > > Are these patches ok to apply? > > 2012-11-19 Michael Meissner <meiss...@linux.vnet.ibm.com> > > * config/rs6000/rs6000.md (movdf_hardfloat32): Reorder move > constraints so that the traditional floating point loads, stores, > and moves are done first, then the VSX loads, stores, and moves, > and finally the GPR loads, stores, and moves so that reload > chooses FPRs over GPRs, and uses the traditional load/store > instructions which provide an offset. > (movdf_hardfloat64): Likewise.
Okay. Thanks, David
