zig0 does not properly handle baseline cpu features

[FanShupei]

Zig Version

0.9.1

Steps to Reproduce

Follow official build instructions on RV64GC linux platform

Expected Behavior

Generate a working stage 2 compiler zig

Actual Behavior

Stage 2 compiler zig does not work at all. It segfault at compiling every trivial program (infinite recursion in __udivmodti4).

When compiling zig by zig0, it generates several warnings

Hard-float 'd' ABI can't be used for a target that doesn't support the D instruction set extension (ignoring target-abi)

Analysis

After investigation, I have found that the root cause is zig0 does not properly set llvm_cpu_names and llvm_cpu_features when handling -mcpu baseline, currently it just leaves the two fields empty.

It may just work (though generating poor code) at x86_64 platform, but it is totally inadequate at rv64gc platform. Without setting cpu names or cpu features, the default cpu used by llvm is rv64i, lacking even basic instructions like multiplication. What's worse, currently even compiler-rt does not support rv64i well. This is why compile-rt contains infinite recursion.

I can not test it on master branch because now compiling zig1.o requires even more memory. but it seems the problem remains.

[andrewrk]

The short-term solution to this problem is to hard-code a different riscv64 cpu features set for zig0.

The eventual solution to this problem is that zig0 will be pure C code that is the zig self-hosted compiler, compiled to C code with the C backend, cleaned up by hand, and with only the C backend available. The bootstrap process will create zig0 from zig0.c, and then use that to produce zig1.c, which will be compiled into zig1, which will then be used to create zig2, which will be used to create the final binary.

[BratishkaErik]

Also see #6830 (comment):

OK, confirmed that the issue is solved by rebuilding, passing [the stage1 that fails the translate-c tests] for -DZIG_EXECUTABLE in order to rebuild zig1.o using stage1 rather than stage0. So this confirms @LemonBoy's hypothesis that stage0 is passing incorrect LLVM CPU features for "baseline", and it also leads us towards a fix, if we can just get cmake to cooperate.