Sorry if this is a duplicate; my previous reply may have been sent as HTML.
Hi Juzhe, Jeff, Thanks for the reviews on v2. Before I post v3, I want to flag a larger interface change that affects several of your comments. LLVM #191349 and riscv-rvv-intrinsic-doc #432 have now both been merged: https://github.com/llvm/llvm-project/pull/191349 https://github.com/riscv-non-isa/riscv-rvv-intrinsic-doc/pull/432 The RVV public intrinsic interface no longer uses uint8 vector types as the carrier for OFP8 values. Instead it uses distinct vfloat8e4m3mfX_t / vfloat8e5m2mfX_t vector types, and the overloaded names have been simplified, e.g. vfncvt_f_bf16_f8e4m3 becomes vfncvt_f_f8e4m3, while vfwcvt_f_f8e4m3_bf16 becomes vfwcvt_f_bf16. I plan to rework v3 around that interface. In particular, the _u8 -> _f8eXmY naming workaround in append_f8_suffix() will go away. For the MD side, I will also address Juzhe's suggestion by carrying the E4M3/E5M2 choice as an explicit operand rather than through an UNSPEC int_iterator. The instruction mnemonic itself does not change; the operand will feed the altfmt instruction attribute used by the vsetvl handling, so the selected format is represented in the vtype state. I'll also fix the smaller comments from v2: add the missing comment for get_altfmt if it remains, update the stale bf16-only comment, revert the gratuitous reformatting, and move SAT-only definitions into the patch that first uses them. Will post v3 once the FP8 vector type plumbing is in place. Thanks, Lino ________________________________________ 寄件者: 钟居哲 <[email protected]> 已傳送: 星期一, 2026 年 5 月 11 日 下午 03:46 收件者: [email protected] <[email protected]> 副本: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Lino Hsing-Yu Peng(彭新佑) <[email protected]>; Li, Pan2 <[email protected]> 主旨: [PATCH v2 0/8] RISC-V: Add zvfofp8min intrinsic support [EXTERNAL MAIL] Hi，Thanks for supporting FP8 extension. After reviewing this series of patches, I saw you define "altfmt" attribute according to "UNSPEC" enum. (define_int_attr altfmt [(UNSPEC_F8E4M3 "f8e4m3") - (UNSPEC_F8E5M2 "f8e5m2")]) + (UNSPEC_F8E5M2 "f8e5m2") + (UNSPEC_F8E4M3_SAT "f8e4m3_sat") + (UNSPEC_F8E5M2_SAT "f8e5m2_sat")]) Is it possible to add an operand to FP8 machine description pattern to specify the "altfmt" like "ta"/"ma" attribute ? By default, all other non-FP8 vector instructions have "altfmt" attribute as "INVALID_ATTRIBUTE", then, specify "altfmt" for FP8 instruction according to operand value like : 0: f8e4m3 1: f8e5m2 2: f8e5m2 ...etc. Then we can avoid creating multiple "UNPSEC" patterns which helps us save machine description patterns. CONFIDENTIALITY NOTICE: This e-mail (and its attachments) may contain confidential and legally privileged information or information protected from disclosure. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein is strictly prohibited. In this case, please immediately notify the sender by return e-mail, delete the message (and any accompanying documents) and destroy all printed hard copies. Thank you for your cooperation. Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.
