[clang] [llvm] [RISCV] Implement Clang Builtins for XCValu Extension in CV32E40P (PR #100684)

[Craig Topper via cfe-commits]

================
@@ -59,16 +59,26 @@ let TargetPrefix = "riscv" in {
                             [IntrNoMem, IntrWillReturn, IntrSpeculatable,
                             ImmArg<ArgIndex<1>>, ImmArg<ArgIndex<2>>]>;
 
+  def int_riscv_cv_alu_slet  : ScalarCoreVAluGprGprIntrinsic;
----------------
topperc wrote:

> Hi @topperc 
> 
> 
> 
> There are a few things going on here.
> 
> 
> 
> 1.  The naming of the corresponding instructions in the CORE-V ISA extension was changed from `slet` to `sle`, and `sletu` to `sleu`.  The CORE-V [standard for builtins](https://github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md) has not yet been updated to reflect this change.  This needs to be fixed through OpenHW group's standardization processes (@PaoloS02 is leading this inside OpenHW Group).
> 
> 
> 
> 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?

> 
> 
> 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?

> 
> 
> 
> So in summary i) it's there because the CORE-V standard for builtins says it should be and ii) it's there to match GCC behavior.
> 
> 
> 
> Hope this is helpful.



https://github.com/llvm/llvm-project/pull/100684