All of lore.kernel.org
 help / color / mirror / Atom feed
From: BALATON Zoltan <balaton@eik.bme.hu>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: qemu-ppc@nongnu.org, luoyonggang@gmail.com,
	"Alex Bennée" <alex.bennee@linaro.org>,
	qemu-devel@nongnu.org
Subject: Re: An first try to improve PPC float simulation, not even compiled. Just ask question.
Date: Mon, 4 May 2020 20:50:57 +0200 (CEST)	[thread overview]
Message-ID: <alpine.BSF.2.22.395.2005042048550.36499@zero.eik.bme.hu> (raw)
In-Reply-To: <dbeeeefc-c208-6549-225e-b3d0ef025679@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 2997 bytes --]

On Mon, 4 May 2020, Richard Henderson wrote:
> On 5/4/20 11:30 AM, BALATON Zoltan wrote:
>> On Mon, 4 May 2020, Richard Henderson wrote:
>>> On 5/3/20 5:41 PM, 罗勇刚(Yonggang Luo) wrote:
>>>> On Mon, May 4, 2020 at 7:40 AM BALATON Zoltan <balaton@eik.bme.hu
>>>> <mailto:balaton@eik.bme.hu>> wrote:
>>>>
>>>>     Hello,
>>>>
>>>>     On Mon, 4 May 2020, 罗勇刚(Yonggang Luo) wrote:
>>>>    > Hello Richard, Can you have a look at the following patch, and was that
>>>> are
>>>>    > the right direction?
>>>>
>>>>     Formatting of the patch is broken by your mailer, try sending it with
>>>>     something that does not change it otherwise it's a bit hard to read.
>>>>
>>>>     Richard suggested to add an assert to check the fp_status is correctly
>>>>     cleared in place of helper_reset_fpstatus first for debugging so you could
>>>>     change the helper accordingly before deleting it and run a few tests to
>>>>     verify it still works. You'll need get some tests and benchmarks working
>>>>     to be able to verify your changes that's why I've said that would be step
>>>>     0. If you checked that it still produces the same results and the assert
>>>>     does not trigger then you can remove the helper.
>>>>
>>>> That's what I need help,
>>>> 1. How to write a assert to replace helper_reset_fpstatus .
>>>>   just directly assert? or something else
>>>
>>> You can't place the assert where helper_reset_fpstatus was.  You need to place
>>> it in each of the helpers, like helper_fadd, that previously has a call to
>>> helper_reset_fpstatus preceeding it.
>>
>> Why? If we want to verify that clearing fp_status after flags are processed is
>> equivalent to clearing flags before fp ops then verifying that the fp_status is
>> already cleared when the current helper_reset_fpstatus is called should be
>> enough to check that nothing has set the flags in between so the current reset
>> helper would be no op. Therefore I thought you could put the assert there for
>> checking this. This assert is for debugging and checking the change only and
>> not meant to be left there otherwise we lose all the performance gain so it's
>> easier to put in the current helper before removing it for this than in every
>> fp op helper. What am I missing?
>
> I'm not sure what you are suggesting.
>
> If you are suggesting
>
> void helper_reset_fpstatus(CPUPPCState *env)
> {
> -    set_float_exception_flags(0, &env->fp_status);
> +    assert(get_float_exception_flags(&env->fp_status) == 0);
> }
>
> then, sure, that works.  But we also want to remove that call, so in order to
> retain the check for debugging, we need to move the assert into the other helpers.

Yes, I meant to change helper_reset_fpstatus as above and add clearing 
fp_status after processing flags then run some tests to verify we can 
remove this call and then remove it together with the assert which should 
not be needed after this checking.

Regards,
BALATON Zoltan

      reply	other threads:[~2020-05-04 18:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01 20:04 An first try to improve PPC float simulation, not even compiled. Just ask question 罗勇刚(Yonggang Luo)
2020-05-01 20:49 ` Richard Henderson
2020-05-01 22:02   ` 罗勇刚(Yonggang Luo)
2020-05-03 19:46   ` 罗勇刚(Yonggang Luo)
2020-05-03 23:40     ` BALATON Zoltan
2020-05-04  0:41       ` 罗勇刚(Yonggang Luo)
2020-05-04 10:04         ` Alex Bennée
2020-05-04 16:49         ` Richard Henderson
2020-05-04 18:30           ` BALATON Zoltan
2020-05-04 18:46             ` Richard Henderson
2020-05-04 18:50               ` BALATON Zoltan [this message]

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=alpine.BSF.2.22.395.2005042048550.36499@zero.eik.bme.hu \
    --to=balaton@eik.bme.hu \
    --cc=alex.bennee@linaro.org \
    --cc=luoyonggang@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=richard.henderson@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.