In reply to @skeuchel:matrix.org
You can always build GHC with an unregisterised backend (via C), and use that to bootstrap. But that is painfully slow. There is no NCG backend and not runtime linker yet, but that's in progress. The LLVM backend "works" as of 9.6 (or 9.4 with newer llvm like in debian).

In my testing using an unregisterised boot GHC, it usually takes around 20 hours to natively build GHC on the JH7110 SoC. Longer if other builds are running in parallel (I've had one GHC build take ~35 hours).

I can't comment on how much faster registerised via LLVM is because my registerised builds keep segfaulting...

GHC is quite tricky to compile, so I'd be pleasantly surprised if Sulong were capable of handling it.

Historically, using Hugs to run GHC on itself has been an option, but AFAIK Hugs doesn't support 64-bit ISAs and it also has a relatively low limit on program size that makes bootstrapping GHC even on x86 a nightmare. I don't know what it would take to support RV64GC and I haven't explored patching Hugs to raise the program size limitations.

Looking into Sulong, apparently it's not a Haskell compiler/interpreter but an LLVM bitcode interpreter?

That doesn't seem suitable for compiling GHC (Haskell code) from source.
LLVM bitcode isn't the problem here.

In reply to @skeuchel:matrix.org
Here are my estimates

On the pioneer:
Unregisterised release+profiled_libs: >30h
Unregisterised quick+no_profiled_libs: 18h
Registerised release+profiled_libs: 12h
Registerised quick+no_profiled_libs: 9h

Using qemu user-mode
Registerised release+profiled_libs: 8h
Registerised quick+no_profiled_libs: 6h

Yeah, the multi-core interconnects are only present to connect the cores, not much more. i.e. not how 64-cores are interconnected on threadrippers/eypcs;

So here, qemu-emulation on x86 will be faster tbh

In reply to @thefossguy:matrix.org

Yeah, the multi-core interconnects are only present to connect the cores, not much more. i.e. not how 64-cores are interconnected on threadrippers/eypcs;

So here, qemu-emulation on x86 will be faster tbh

In reply to @shalokshalom:kde.org
Hugs is even older than Eta, so I doubt very much it can compile any modern Haskell code at all?

the C910 has two classes of issues:

1. non-standard features for things that eventually became standard, i.e. RVV 0.7.1, MAEE instead of Svpbmt (needed for PCIe because Intel didn't distinguish BARs by memory type, irrelevant otherwise), T-Head performance counters, etc. None of this affects software that doesn't opt in to using the pre-standard feature, and none of it is morally different from any other non-standard extension, which are likely to be ubiquitous
2. ordinary bugs - unreasonably slow contended memory access without fences, wrong decoding of noncanonical fences, wrong FP underflow flag - there is no reason to believe that future, more complicated cores will have fewer total bugs, even if they fix the current bugs, and also no evidence that the C910's crop of bugs can cause successful builds with miscompilations