Regarding FPU workarounds for chibicc

[fuhsnn]

Hi, here is a minimal diff for chibicc to pass RVVM's test suite as FPU_LIB_KNOWN_SANE_COMPILER.
(Weird post, I know, I just got my chibicc fork working with RVVM and thought this might help reduce some special casing)

chibicc diff

diff --git a/codegen.c b/codegen.c
index da11fd7..5f32fa6 100644
--- a/codegen.c
+++ b/codegen.c
@@ -322,7 +322,10 @@ static char i64f32[] = "cvtsi2ssq %rax, %xmm0";
 static char i64f64[] = "cvtsi2sdq %rax, %xmm0";
 static char i64f80[] = "movq %rax, -8(%rsp); fildll -8(%rsp)";
 
-static char u64f32[] = "cvtsi2ssq %rax, %xmm0";
+static char u64f32[] =
+  "test %rax,%rax; js 1f; cvtsi2ss %rax,%xmm0; jmp 2f; "
+  "1: mov %rax,%rdx; and $1,%eax; shr $1, %rdx; "
+  "or %rax,%rdx; cvtsi2ss %rdx,%xmm0; addss %xmm0,%xmm0; 2:";
 static char u64f64[] =
   "test %rax,%rax; js 1f; pxor %xmm0,%xmm0; cvtsi2sd %rax,%xmm0; jmp 2f; "
   "1: mov %rax,%rdi; and $1,%eax; pxor %xmm0,%xmm0; shr %rdi; "
@@ -338,7 +341,9 @@ static char f32u16[] = "cvttss2sil %xmm0, %eax; movzwl %ax, %eax";
 static char f32i32[] = "cvttss2sil %xmm0, %eax";
 static char f32u32[] = "cvttss2siq %xmm0, %rax";
 static char f32i64[] = "cvttss2siq %xmm0, %rax";
-static char f32u64[] = "cvttss2siq %xmm0, %rax";
+static char f32u64[] =
+  "movl $0x5F000000, %eax; movd %eax, %xmm1; comiss %xmm0, %xmm1; setbe %%al; ja 1f; "
+  "subss %xmm1, %xmm0; 1: cvttss2siq %xmm0, %rdx; shlq $63, %rax; orq %rdx, %rax";
 static char f32f64[] = "cvtss2sd %xmm0, %xmm0";
 static char f32f80[] = "movss %xmm0, -4(%rsp); flds -4(%rsp)";
 
@@ -349,7 +354,9 @@ static char f64u16[] = "cvttsd2sil %xmm0, %eax; movzwl %ax, %eax";
 static char f64i32[] = "cvttsd2sil %xmm0, %eax";
 static char f64u32[] = "cvttsd2siq %xmm0, %rax";
 static char f64i64[] = "cvttsd2siq %xmm0, %rax";
-static char f64u64[] = "cvttsd2siq %xmm0, %rax";
+static char f64u64[] =
+  "mov $0x43e0000000000000, %rax; movq %rax, %xmm1; comisd %xmm0, %xmm1; setbe %%al; ja 1f; "
+  "subsd %xmm1, %xmm0; 1: cvttsd2siq %xmm0, %rdx; shlq $63, %rax; orq %rdx, %rax";
 static char f64f32[] = "cvtsd2ss %xmm0, %xmm0";
 static char f64f80[] = "movsd %xmm0, -8(%rsp); fldl -8(%rsp)";
 
@@ -1029,7 +1036,10 @@ static void gen_expr(Node *node) {
     case ND_NE:
     case ND_LT:
     case ND_LE:
-      println("  ucomi%s %%xmm0, %%xmm1", sz);
+      if (node->kind == ND_EQ || node->kind == ND_NE)
+        println("  ucomi%s %%xmm0, %%xmm1", sz);
+      else
+        println("  comi%s %%xmm0, %%xmm1", sz);
 
       if (node->kind == ND_EQ) {
         println("  sete %%al");

[LekKit]

Very cool.
For future reference, the FPU_LIB_KNOWN_SANE_COMPILER is more of "apply workarounds until we definitely know things are working correctly", and even then it also is disabled on GCC <8.1, Clang <12.0 because they had various IEEE 754 conformance bugs back then, and it has little performance overhead. This flag enables FPU_LIB_CORRECT_CONVERSION_LONG_FP, FPU_LIB_CORRECT_CONVERSION_FP_LONG, FPU_LIB_CORRECT_SIGNALING_COMPARE, but many are also covered under a specific architecture.

Would it be a good idea to ifdef __slimcc__ for enabling FPU_LIB_KNOWN_SANE_COMPILER?

Also some bugs I noticed in chibicc and simply ifdef'd out for a fallback/macro implementation, because that compiler seems abandoned, maybe this will be of use:

• Broken C11 atomics (They are not actually atomic, see <stdatomic.h>). RVVM currently fallbacks to directly calling libatomic functions when neither GNU/C11/Win32 atomics are available, which may be used to implement <stdatomic.h> intrisics, but not the _Atomic types because that requires actual compiler instrumentation:

#define atomic_load(addr) ((sizeof(*(addr)) == 8) ? __atomic_load_8(addr) : __atomic_load_4(addr))

• Missing C11 _Static_assert(), may be implemented like this:

#define _Static_assert(cond, diagnostic) typedef char static_assert_at_line_##__LINE__[(cond && diagnostic) ? 1 : -1]

[fuhsnn]

IEEE 754 conformance bugs

I only learnt to not mixed up ucomi/comi from fixing RVVM test failures, really appreciate your comments.

Would it be a good idea to ifdef slimcc for enabling FPU_LIB_KNOWN_SANE_COMPILER?

I'll be running RVVM test with -std=c11/GNU_EXT/FPU_LIB_KNOWN_SANE_COMPILER enabled for extra coverage, but there might be undiscovered brokenness lurking around, so I don't mind it using safer code path by default.

Also some bugs I noticed in chibicc and simply ifdef'd out for a fallback/macro implementation, because that compiler seems abandoned,

Yeah I also have a list in my repo's issues. Upstream author is busy with mold linker, but commits in my fork are hopefully clean enough to cherry-pick for anyone intend to work on chibicc. If you came across other chibicc issues that hasn't been fixed in slimcc I would certainly try to work on it.

[LekKit]

RVVM compiled via SlimCC is running an SMP ArchRISCV guest with Gnome X)

This might help reduce some special casing

Unfortunately not really, the Cproc and XCC compilers still fumble uint<->fp conversions, and ARM32/MIPS/LoongArch fail u64 conversions specifically, even on modern GCC/Clang. I also didn't even test MSVC yet...
However the effort in correct behavior is very respected.

I'll be running RVVM test with -std=c11/GNU_EXT/FPU_LIB_KNOWN_SANE_COMPILER

Note that RVVM actually undefines GNU_EXTS and most other feature macros if conditions are not satisfied (I.e. will actually undefine GNU_EXTS on non-GCC/LLVM/Intel compiler):

RVVM/src/compiler.h

Line 19 in e2ecbf0

#undef GNU_EXTS

Given that SlimCC actually supports inline assembly and __thread TLS attribute (nice work), I think I will actually enable GNU_EXTS and FPU_LIB_KNOWN_SANE_COMPILER on __slimcc__ by default. I don't see reasons not to (Plus future inline asm may improve SlimCC coverage).

The TLS attribute is really important for proper RCU, which is out there in the codebase but not actually used yet. It is planned to be used in networking stack and JIT. Without TLS attribute, RCU will fallback to a slow global-locked implementation.