[PATCH] D150929: [RISCV][BF16] Enable __bf16 for riscv targets

This revision was automatically updated to reflect the committed changes. Closed by commit rGa5791bfef4e4: [RISCV][BF16] Enable __bf16 for riscv targets (authored by joshua-arch1). Herald added a project: clang. Herald added a subscriber: cfe-commits. Changed prior to commit:

[PATCH] D152768: [Clang][BFloat16] Upgrade __bf16 by supporting increment/decrement operations

This revision was automatically updated to reflect the committed changes. Closed by commit rG62a251f824f6: [Clang][BFloat16] Upgrade __bf16 by supporting increment/decrement operations (authored by joshua-arch1). Herald added a project: clang. Herald added a subscriber: cfe-commits. Changed

[PATCH] D155916: [RISCV] Remove some instructions from Zvfbfwma by implying Zfbfmin according to the latest spec

This revision was automatically updated to reflect the committed changes. Closed by commit rGe56bf133170c: [RISCV] Remove some instructions from Zvfbfwma by implying Zfbfmin according to… (authored by joshua-arch1). Herald added a project: clang. Herald added a subscriber: cfe-commits. Changed

[PATCH] D147610: [RISCV][MC] Add support for experimental Zfbfmin extension

joshua-arch1 added a comment. Can you merge this patch since I want to suppport support __bf16 in clang which will rely on FeatureStdExtZfbfmin? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D147610/new/ https://reviews.llvm.org/D147610 ___

[PATCH] D147610: [RISCV][MC] Add support for experimental Zfbfmin extension

joshua-arch1 added a comment. > The RVI toolchain SIG is supposed to be setting up a task group to define > intrinsics for all extensions. Where should I discuss this intrinsic issue right now? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D147610/new/ https://reviews.llvm.org/D147610

[PATCH] D147610: [RISCV][MC] Add support for experimental Zfbfmin extension

joshua-arch1 added a comment. In D147610#4294260 , @craig.topper wrote: > In D147610#4294247 , @joshua-arch1 > wrote: > >> I'm wondering whether it is appropriate to just use FPR16 for the >> destination of

[PATCH] D147610: [RISCV][MC] Add support for experimental Zfbfmin extension

joshua-arch1 added a comment. I'm wondering whether it is appropriate to just use FPR16 for the destination of fcvt.bf16.s? The destination is in BF16 format instead of simple FP16. Your implemention looks like just replacing fcvt.h.s with fcvt.bf16.s. Do we need to define a new register

[PATCH] D147610: [RISCV][MC] Add support for experimental Zfbfmin extension

joshua-arch1 added a comment. What's the difference between fcvt.bf16.s and fcvt.h.s? In your implementation, it seems that you just replace fcvt.h.s with fcvt.bf16.s in Zfbfmin extension. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D147610/new/ https://reviews.llvm.org/D147610

[PATCH] D148617: [RISCV] Remove 'sx' when parsing arch string to match the latest ISA manual

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG3f81d25cee70: [RISCV] Remove sx when parsing arch string to match the latest ISA manual (authored by joshua-arch1). Herald added a project: clang.

[PATCH] D148315: [RISCV] Modify arch string parsing order according to latest riscv spec

joshua-arch1 added a comment. In D148315#4279486 , @asb wrote: > I'm starting to think we should just remove the ordering rules for z/s/x > altogether when parsing arch strings I see that gcc 12.2.0 actually requires > s and then z: > > [asb@purge

[PATCH] D148315: [RISCV] Modify arch string parsing order according to latest riscv spec

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGf98ca363bed7: [RISCV] Modify arch string parsing order according to latest riscv spec (authored by joshua-arch1). Herald added a project: clang.

[PATCH] D121670: [RISCV] Add zihintntl instructions

joshua-arch1 added a comment. Herald added subscribers: jobnoorman, luke. It seems that llvm implementation is different from Binutils/GCC. Binutils didn't regard ntl instructions as aliases of add since encoding space is reserved for HINT instructions. Repository: rG LLVM Github Monorepo

[PATCH] D144935: Add missing roundtointegral builtin functions for some FP instructions to be generated from C-written codes

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGa7d6593a0a17: Add missing roundtointegral builtin functions for some FP instructions to be… (authored by joshua-arch1). Herald added a project: