From: Tom Musta <tommusta@gmail.com>
To: Alexander Graf <agraf@suse.de>,
qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [2.3 V2 PATCH 2/6] target-ppc: Fix Floating Point Move Instructions That Set CR1
Date: Thu, 20 Nov 2014 08:32:39 -0600 [thread overview]
Message-ID: <546DFB87.80609@gmail.com> (raw)
In-Reply-To: <546DF731.2060303@suse.de>
On 11/20/2014 8:14 AM, Alexander Graf wrote:
>
>
> On 12.11.14 22:46, Tom Musta wrote:
>> The Floating Point Move instructions (fmr., fabs., fnabs., fneg.,
>> and fcpsgn.) incorrectly copy FPSCR[FPCC] instead of [FX,FEX,VX,OX].
>> Furthermore, the current code does this via a call to gen_compute_fprf,
>> which is awkward since these instructions do not actually set FPRF.
>>
>> Change the code to use the gen_set_cr1_from_fpscr utility.
>>
>> Signed-off-by: Tom Musta <tommusta@gmail.com>
>> ---
>> target-ppc/translate.c | 50 ++++++++++++++++++++++++++++-------------------
>> 1 files changed, 30 insertions(+), 20 deletions(-)
>>
>> diff --git a/target-ppc/translate.c b/target-ppc/translate.c
>> index 910ce56..2d79e39 100644
>> --- a/target-ppc/translate.c
>> +++ b/target-ppc/translate.c
>> @@ -2077,6 +2077,21 @@ static void gen_srd(DisasContext *ctx)
>> }
>> #endif
>>
>> +#if defined(TARGET_PPC64)
>> +static void gen_set_cr1_from_fpscr(DisasContext *ctx)
>> +{
>> + TCGv_i32 tmp = tcg_temp_new_i32();
>> + tcg_gen_trunc_tl_i32(tmp, cpu_fpscr);
>> + tcg_gen_shri_i32(cpu_crf[1], tmp, 28);
>> + tcg_temp_free_i32(tmp);
>> +}
>> +#else
>> +static void gen_set_cr1_from_fpscr(DisasContext *ctx)
>> +{
>> + tcg_gen_shri_tl(cpu_crf[1], cpu_fpscr, 28);
>> +}
>> +#endif
>> +
>> /*** Floating-Point arithmetic ***/
>> #define _GEN_FLOAT_ACB(name, op, op1, op2, isfloat, set_fprf, type) \
>> static void gen_f##name(DisasContext *ctx) \
>> @@ -2370,7 +2385,9 @@ static void gen_fabs(DisasContext *ctx)
>> }
>> tcg_gen_andi_i64(cpu_fpr[rD(ctx->opcode)], cpu_fpr[rB(ctx->opcode)],
>> ~(1ULL << 63));
>> - gen_compute_fprf(cpu_fpr[rD(ctx->opcode)], 0, Rc(ctx->opcode) != 0);
>> + if (unlikely(Rc(ctx->opcode))) {
>> + gen_set_cr1_from_fpscr(ctx);
>> + }
>
> I don't quite understand this. We set cr1 based on fpscr, but we don't
> recalculate the respective fpscr bits?
>
> Wouldn't we get outdated comparison data?
>
>
> Alex
>
Nope.
The floating point move instructions don't actually even alter the FPSCR. From the ISA (see the last sentence):
4.6.5 Floating-Point Move Instructions
These instructions copy data from one floating-point
register to another, altering the sign bit (bit 0) as
described below for fneg, fabs, fnabs, and fcpsgn.
These instructions treat NaNs just like any other kind of
value (e.g., the sign bit of a NaN may be altered by
fneg, fabs, fnabs, and fcpsgn). These instructions do
not alter the FPSCR.
next prev parent reply other threads:[~2014-11-20 14:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-12 21:45 [Qemu-devel] [2.3 V2 PATCH 0/6] target-ppc: Assorted Floating Point Bugs and Cleanup Tom Musta
2014-11-12 21:45 ` [Qemu-devel] [2.3 V2 PATCH 1/6] target-ppc: VXSQRT Should Not Be Set for NaNs Tom Musta
2014-11-12 21:46 ` [Qemu-devel] [2.3 V2 PATCH 2/6] target-ppc: Fix Floating Point Move Instructions That Set CR1 Tom Musta
2014-11-20 14:14 ` Alexander Graf
2014-11-20 14:32 ` Tom Musta [this message]
2014-11-20 14:49 ` Alexander Graf
2014-11-12 21:46 ` [Qemu-devel] [2.3 V2 PATCH 3/6] target-ppc: mffs. Should Set CR1 from FPSCR Bits Tom Musta
2014-11-12 21:46 ` [Qemu-devel] [2.3 V2 PATCH 4/6] target-ppc: Fully Migrate to gen_set_cr1_from_fpscr Tom Musta
2014-11-12 21:46 ` [Qemu-devel] [2.3 V2 PATCH 5/6] target-ppc: Eliminate set_fprf Argument From gen_compute_fprf Tom Musta
2014-11-12 21:46 ` [Qemu-devel] [2.3 V2 PATCH 6/6] target-ppc: Eliminate set_fprf Argument From helper_compute_fprf Tom Musta
2014-11-20 14:51 ` [Qemu-devel] [2.3 V2 PATCH 0/6] target-ppc: Assorted Floating Point Bugs and Cleanup Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546DFB87.80609@gmail.com \
--to=tommusta@gmail.com \
--cc=agraf@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).