public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: 钟居哲 <juzhe.zhong@rivai.ai>
To: "Jeff Law" <jeffreyalaw@gmail.com>,
	 gcc-patches <gcc-patches@gcc.gnu.org>
Cc: kito.cheng <kito.cheng@gmail.com>,
	 kito.cheng <kito.cheng@sifive.com>,  palmer <palmer@dabbelt.com>,
	 palmer <palmer@rivosinc.com>,  rdapp.gcc <rdapp.gcc@gmail.com>
Subject: Re: Re: [PATCH] RISC-V: Add rounding mode operand for floating point instructions
Date: Mon, 15 May 2023 21:54:52 +0800	[thread overview]
Message-ID: <E7993A05483AAA09+202305152154519282643@rivai.ai> (raw)
In-Reply-To: <d40b9972-5d0f-ab6e-edd4-849a23909ed4@gmail.com>

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

I don't know why we should not add frm vfsqrt.v since I saw topper (LLVM maintainer) said we should
not add frm into vsqrt.v. Maybe kito knows the reason ?

https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/226 




juzhe.zhong@rivai.ai
 
From: Jeff Law
Date: 2023-05-15 21:52
To: juzhe.zhong; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Add rounding mode operand for floating point instructions
 
 
On 5/15/23 05:49, juzhe.zhong@rivai.ai wrote:
> From: Juzhe-Zhong <juzhe.zhong@rivai.ai>
> 
> This patch is adding rounding mode operand and FRM_REGNUM dependency
> into floating-point instructions.
> 
> The floating-point instructions we added FRM and rounding mode operand:
> 1. vfadd/vfsub
> 2. vfwadd/vfwsub
> 3. vfmul
> 4. vfdiv
> 5. vfwmul
> 6. vfwmacc/vfwnmacc/vfwmsac/vfwnmsac
> 7. vfsqrt7/vfrec7
> 8. floating-point conversions.
> 9. floating-point reductions.
> 
> The floating-point instructions we did NOT add FRM and rounding mode operand:
> 1. vfsqrt/vfneg
Assuming vfsqrt is actually an estimator the best place to handle 
rounding modes is at the last step(s) after N-R or Goldschmidt 
refinement steps.  I haven't paid too much attention to FP yet, but this 
is an area I've got fairly extensive experience.
 
Sadly RISC-V's estimator is fairly poor and the single instance FMACs 
are going to result in an implementation that may not actually be any 
better than what glibc can do.
 
Jeff
 

  reply	other threads:[~2023-05-15 13:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-15 11:49 juzhe.zhong
2023-05-15 13:44 ` Kito Cheng
2023-05-15 13:52   ` Jeff Law
2023-05-15 13:52 ` Jeff Law
2023-05-15 13:54   ` 钟居哲 [this message]
2023-05-15 14:07     ` Kito Cheng
2023-05-15 14:08       ` 钟居哲
2023-05-15 14:12       ` 钟居哲
2023-05-15 14:22         ` Kito Cheng
2023-05-15 14:24           ` 钟居哲
2023-05-15 14:28           ` 钟居哲
2023-05-15 14:37           ` 钟居哲
2023-05-15 14:41             ` Kito Cheng
2023-05-15 14:55               ` 钟居哲
2023-05-16  3:56     ` Jeff Law

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=E7993A05483AAA09+202305152154519282643@rivai.ai \
    --to=juzhe.zhong@rivai.ai \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=kito.cheng@gmail.com \
    --cc=kito.cheng@sifive.com \
    --cc=palmer@dabbelt.com \
    --cc=palmer@rivosinc.com \
    --cc=rdapp.gcc@gmail.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).