public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Jin Ma <jinma@linux.alibaba.com>, gcc-patches@gcc.gnu.org
Cc: palmer@dabbelt.com, richard.sandiford@arm.com,
	kito.cheng@gmail.com, philipp.tomsich@vrull.eu,
	christoph.muellner@vrull.eu, rdapp.gcc@gmail.com,
	juzhe.zhong@rivai.ai, jinma.contrib@gmail.com
Subject: Re: [RFC 1/2] RISC-V: Add support for _Bfloat16.
Date: Fri, 29 Sep 2023 11:46:52 -0600	[thread overview]
Message-ID: <0635e268-2181-437d-a1e9-a8f9c27d90bd@gmail.com> (raw)
In-Reply-To: <20230919084444.2089-1-jinma@linux.alibaba.com>



On 9/19/23 02:44, Jin Ma wrote:
> gcc/ChangeLog:
> 
> 	* config/riscv/iterators.md (HFBF): New.
> 	* config/riscv/riscv-builtins.cc (riscv_init_builtin_types):
> 	Initialize data type_Bfloat16.
> 	* config/riscv/riscv-modes.def (FLOAT_MODE): New.
> 	(ADJUST_FLOAT_FORMAT): New.
> 	* config/riscv/riscv.cc (riscv_mangle_type): Support for BFmode.
> 	(riscv_scalar_mode_supported_p): Ditto.
> 	(riscv_libgcc_floating_mode_supported_p): Ditto.
> 	(riscv_block_arith_comp_libfuncs_for_mode): New.
> 	(riscv_init_libfuncs): Opening and closing some libfuncs for BFmode.
> 	* config/riscv/riscv.md (mode" ): Add BF.
> 	(truncdfbf2): New.
> 	(movhf): Support for BFmode.
> 	(mov<mode>): Ditto.
> 	(*mov<mode>_softfloat):  Ditto.
> 	(fix_truncbf<GPR:mode>2): New.
> 	(fixuns_truncbf<GPR:mode>2): New.
> 	(float<mode>bf2): New.
> 	(floatuns<mode>bf2): New.
> 
> libgcc/ChangeLog:
> 
> 	* config/riscv/sfp-machine.h (_FP_NANFRAC_B): New.
> 	(_FP_NANSIGN_B): New.
> 	* config/riscv/t-softfp32: Add support for BF libfuncs.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* gcc.target/riscv/bf16_arithmetic.c: New test.
> 	* gcc.target/riscv/bf16_call.c: New test.
> 	* gcc.target/riscv/bf16_comparisons.c: New test.
> 	* gcc.target/riscv/bf16_convert-1.c: New test.
> 	* gcc.target/riscv/bf16_convert-2.c: New test.
> 	* gcc.target/riscv/bf16_convert_run.c: New test.
So this can't go in the tree until the extension has moved into a frozen 
state.  Hopefully that'll happen before we close stage1 development in Nov.



> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index e00b8ee3579..5048628c784 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -1631,6 +1631,20 @@ (define_insn "truncdfhf2"
>     [(set_attr "type" "fcvt")
>      (set_attr "mode" "HF")])
>   
> +;; The conversion of DF to BF needs to be done with SF if there is a
> +;; chance to generate at least one instruction, otherwise just using
> +;; libfunc __truncdfbf2.
> +(define_expand "truncdfbf2"
> +  [(set (match_operand:BF     0 "register_operand" "=f")
> +       (float_truncate:BF
> +           (match_operand:DF 1 "register_operand" " f")))]
> +  "TARGET_DOUBLE_FLOAT || TARGET_ZDINX"
> +  {
> +    convert_move (operands[0],
> +		  convert_modes (SFmode, DFmode, operands[1], 0), 0);
> +    DONE;
> +  })
So for conversions to/from BFmode, doesn't generic code take care of 
this for us?  Search for convert_mode_scalar in expr.cc. That code will 
utilize SFmode as an intermediate step just like your expander.   Is 
there some reason that generic code is insufficient?

Similarly for the the other conversions.

Otherwise it looks pretty good.

Jeff

  parent reply	other threads:[~2023-09-29 17:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19  8:44 Jin Ma
2023-09-19  8:46 ` [RFC 2/2] RISC-V: Add 'Zfbfmin' extension Jin Ma
2023-09-29 17:52   ` Jeff Law
2023-09-29 17:46 ` Jeff Law [this message]
2023-10-09  6:18   ` [RFC 1/2] RISC-V: Add support for _Bfloat16 Jin Ma
2023-10-09 19:16     ` Jeff Law
2023-10-25 10:15       ` Jin Ma
2023-11-10 21:21         ` Jeff Law
2023-12-20 11:17 ` [PATCH] Support libcall __float{,un}sibf by SF when it is not supported for _bf16 Jin Ma
2024-01-09  9:32   ` Jin Ma
2024-01-09  9:43     ` Jin Ma
2024-05-26 14:53   ` [PATCH] " Jeff Law
2024-06-05  6:18     ` Jin Ma

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=0635e268-2181-437d-a1e9-a8f9c27d90bd@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=christoph.muellner@vrull.eu \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jinma.contrib@gmail.com \
    --cc=jinma@linux.alibaba.com \
    --cc=juzhe.zhong@rivai.ai \
    --cc=kito.cheng@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=rdapp.gcc@gmail.com \
    --cc=richard.sandiford@arm.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).