This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PowerPC, PR60735: _Decimal64 moves broken on -mspe
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Michael Meissner <meissner at linux dot vnet dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, David Edelsohn <dje dot gcc at gmail dot com>, wschmidt at gcc dot gnu dot org, bergner at gcc dot gnu dot org
- Date: Tue, 1 Apr 2014 22:17:35 -0400
- Subject: Re: [PATCH] PowerPC, PR60735: _Decimal64 moves broken on -mspe
- Authentication-results: sourceware.org; auth=none
- References: <20140401235502 dot GA18885 at ibm-tiger dot the-meissners dot org>
On Tue, Apr 1, 2014 at 7:55 PM, Michael Meissner
<meissner@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 <meissner@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