Compiling FIR code for RISC-V target

[sitio-couto]

Hey,

I'm trying to compile a Fortran hello world source code through FIR to run on a RISC-V target using Chipyard.

It looks something like this:

# lower Fortran to MLIR
bbc hello.f90 -emit-fir -o hello.mlir

# lower MLIR to LLVM IR
tco hello.mlir -o hello.ll

# lower LLVM IR to assembly
llc hello.ll -O3 -filetype=obj -march=riscv64 -o hello.o

# link and compile to machine code
riscv64-unknown-elf-gcc -static hello.o -o hello.riscv \
    $FIR_LIB/libFortran_main.a \
    $FIR_LIB/libFortranRuntime.a

However, it fails when linking the RISC-V program with the libraries since they are not compatible with RISC-V:

/root/chipyard/esp-tools-install/lib/gcc/riscv64-unknown-elf/9.2.0/../../../../riscv64-unknown-elf/bin/ld: /root/builds/fir-build/lib/libFortran_main.a(Fortran_main.c.o): Relocations in generic ELF (EM: 62)
/root/chipyard/esp-tools-install/lib/gcc/riscv64-unknown-elf/9.2.0/../../../../riscv64-unknown-elf/bin/ld: /root/builds/fir-build/lib/libFortran_main.a(Fortran_main.c.o): Relocations in generic ELF (EM: 62)
/root/chipyard/esp-tools-install/lib/gcc/riscv64-unknown-elf/9.2.0/../../../../riscv64-unknown-elf/bin/ld: /root/builds/fir-build/lib/libFortran_main.a: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status

I haven't found a proper way to compile Fortran code to RISC-V, especially when going through FIR.

Is it currently possible to compile FIR code to a RISC-V target?

[jeanPerier]

Hi, thanks for reporting the issue, it is exiting to see flang being tested on new platforms (I am not aware RISC-V was already tested) !

I am not familiar with Chipyard, are you cross-compiling to RISC-V or was the host compiler (LLVM with flang) also compiled on RISC-V ? From the error you are reporting, it looks like the issue is that the flang runtime libraries libFortran_main.a and libFortranRuntime.a may not have been compiled on/for RISC-V.

We have never tried cross-compiling yet, so I am not entirely sure what are all the steps/changes that are needed. The first one I see is to compile a version of the runtime libraries for the target. Then, you may still experience some troubles if the C types between the flang host and the target maps to different hardware type (e.g. long double). This is because or runtime call code generation uses a simple mapping from the C++ runtime type to the FIR types based on the host (in RTBuilder.h). If you are willing to try bring the target triple here to change that, that would be great !

[sitio-couto]

Hey @jeanPerier,

are you cross-compiling to RISC-V or was the host compiler (LLVM with flang) also compiled on RISC-V ?

I was trying to create a Flang that could cross-compile to RISCV, so both the build and host machines are X86, only the target that was changed to RISCV. The approach used was an adaptation of these instructions to create a Clang cross-compiler. I've also tried cross-compiling Flang itself in an attempt to generate the runtime libraries to a RISCV host, but it didn't work either.

libFortran_main.a and libFortranRuntime.a may not have been compiled on/for RISC-V.

That does seem to be the case, and a good first step to try. I've noticed that the libraries are all C++, so trying to cross-compiling them without any alterations to the source code might be possible.

In order to cross-compile these libraries, I'm trying to edit the CMake instructions to use the proper target architecture flags when generating the libraries. From what I've looked so far, it seems that the right place to do it would be in the fir-dev/flang/cmake/modules/AddFlang.cmake file. Do you think this might work?

Sorry about the (very) late answer.

[banach-space]

I would try avoid the cross-compilation path (from here):

// TODO: It is understood that this is deeply incorrect as far as building a
// portability layer for cross-compilation as these reflected types are those of
// the build machine and not necessarily that of either the host or the target.
// This assumption that build == host == target is actually pervasive across the
// compiler (https://llvm.org/PR52418).

Also, I would try experimenting with Flang's compiler driver, flang-new. It's just easier to use one tool instead of 3 or 4.