On Tue, Apr 1, 2014 at 7:55 PM, Michael Meissner <meiss...@linux.vnet.ibm.com> wrote: > In backporting the power8 changes to the 4.8 branch, one of the testers of > these patches noticed that libgcc cannot be built on a linux SPE target. The > reason was the _Decimal64 type did not have a proper move insn in the SPE > environment. This patch fixes that issue. In looking at the patch, I > discovered two other thinkos that are fixed in this patch. > > The first problem is the movdf/movdd insns for 32-bit without hardware > floating > point, checked whether we had hardware single precision support, when it > should > have been checking that we had hardware double precision support. > > The second problem was that some of the types believed they could use the > floating point registers in a SPE or software emulation enviornment. So I > added additional code to turn off the use of the FPRs in this case. > > I have done bootstraps and make check on 64-bit PowerPC linux systems with no > regression. In addition, I tested the code generated using cross compilers to > the Linux SPE system. Is this patch acceptible to be checked in the trunk > (and > to the 4.8 branch when the other patches are approved)? > > 2014-04-01 Michael Meissner <meiss...@linux.vnet.ibm.com> > > PR target/60735 > * config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok): If we have > software floating point or no floating point registers, do not > allow any type in the FPRs. Eliminate a test for SPE SIMD types > in GPRs that occurs after we tested for GPRs that would never be > true. > > * config/rs6000/rs6000.md (mov<mode>_softfloat32, FMOVE64): > Rewrite tests to use TARGET_DOUBLE_FLOAT and TARGET_E500_DOUBLE, > since the FMOVE64 type is DFmode/DDmode. If TARGET_E500_DOUBLE, > specifically allow DDmode, since that does not use the SPE SIMD > instructions.
Okay for trunk and the 4.8 backport. Thanks, David
