[clang] [llvm] [RISCV] Implement Clang Builtins for XCValu Extension in CV32E40P (PR #100684)
Jeremy Bennett via cfe-commits
cfe-commits at lists.llvm.org
Fri Aug 16 05:39:51 PDT 2024
================
@@ -59,16 +59,26 @@ let TargetPrefix = "riscv" in {
[IntrNoMem, IntrWillReturn, IntrSpeculatable,
ImmArg<ArgIndex<1>>, ImmArg<ArgIndex<2>>]>;
+ def int_riscv_cv_alu_slet : ScalarCoreVAluGprGprIntrinsic;
----------------
jeremybennett wrote:
> > Hi @topperc
> > There are a few things going on here.
@topperc Thanks for this. Apologies if my original comment was a bit clumsy. I was trying to explain where we were, not where we should go!
<snip>
> > 2. These instructions only exist for "less than or equal", there are no equivalents for other comparison predicates, hence just these two builtins mapping to the instructions.
>
> I was referring to the stand comparisons. We don't have builtins for writing slt, we expect the programmer to write (a< b) and the backend will figure it out. slte can be automatically selected from (a<=b). Why do we need a builtin too?
I understand.
> > 3. LLVM and GCC for CORE-V are intended to be equivalent, and in GCC, having the builtin to generate the instruction is more efficient than using inline assembler. First the dataflow through the instruction is explicit, secondly the pattern for the functionality is exposed to GCC, potentially allowing the instruction to be generated automatically in other circumstances.
>
> Since gcc already has the builtin, I guess we have to be source compatible. Would it be ok to map the builtin to (zext (icmp sle a,b) in IR and let the middle end and backend treat it like any other compare?
This is fine. We just want to make sure that any legacy code written for GCC is not too painful to switch to LLVM for the owners.
https://github.com/llvm/llvm-project/pull/100684
More information about the cfe-commits
mailing list