LLVM_WASM: Initial support for LLVM->WASM Backend #3842
Conversation
| add_custom_command(OUTPUT lfortran_runtime_wasm.o | ||
| COMMAND $ENV{WASI_SDK_PATH}/bin/clang -I${libasr_SOURCE_DIR}/.. -DCOMPILE_TO_WASM -D_WASI_EMULATED_PROCESS_CLOCKS -c --target=wasm32-wasi ${SRC} -o lfortran_runtime_wasm.o | ||
| COMMENT "Cross compiling lfortran_intrinscs.c to lfortran_runtime_wasm.o" | ||
| DEPENDS ${SRC}) |
There was a problem hiding this comment.
You need to check the output of this and fail if it fails to run. Check status.
There was a problem hiding this comment.
I think it fails currently by default.
|
Let's document somewhere how to use this: Download: https://github.com/WebAssembly/wasi-sdk/releases diff --git a/build1.sh b/build1.sh
index 49a1cf78b..d2a865215 100755
--- a/build1.sh
+++ b/build1.sh
@@ -3,6 +3,8 @@
set -e
set -x
+export WASI_SDK_PATH="$HOME/ext/wasi-sdk-21.0"
+
cmake \
-DCMAKE_BUILD_TYPE=Debug \
-DWITH_LLVM=yes \
@@ -12,5 +14,6 @@ cmake \
-DCMAKE_PREFIX_PATH="$CMAKE_PREFIX_PATH_LFORTRAN;$CONDA_PREFIX" \
-DCMAKE_INSTALL_PREFIX=`pwd`/inst \
-DCMAKE_INSTALL_LIBDIR=share/lfortran/lib \
+ -DWITH_TARGET_WASM=yes \
.
cmake --build . -j16 --target installTo test this: $ export WASI_SDK_PATH="$HOME/ext/wasi-sdk-21.0"
$ lfortran --target=wasm32-wasi examples/expr2.f90
25
$ wasmtime expr2.out
25 |
|
Let's give good error message for |
|
|
||
| if(WITH_TARGET_WASM) | ||
| add_custom_command(OUTPUT lfortran_runtime_wasm.o | ||
| COMMAND $ENV{WASI_SDK_PATH}/bin/clang -I${libasr_SOURCE_DIR}/.. -DCOMPILE_TO_WASM -D_WASI_EMULATED_PROCESS_CLOCKS -c --target=wasm32-wasi ${SRC} -o lfortran_runtime_wasm.o |
There was a problem hiding this comment.
This was not a good idea!
Neither is the compiler always in bin/ nor is it always called clang.
I also got tripped up by the fact that WITH_TARGET_WASM is a CMake Variable, but WASI_SDK_PATH is an environment variable, very inconsistent.
I think we shouldn't never hard-code paths or compiler names, Debian has a patch about that, too:
https://sources.debian.org/patches/lfortran/0.35.0-1/clang-16.patch/
There was a problem hiding this comment.
Thanks @junghans. I agree that we should not hard-code paths. I wanted to use the clang compiler from WASI SDK for this specific compilation (or cross-compilation). Rest of the project needs to be built using the normal/regular clang. I attempted looking into how one could compile specific files using a different compiler and it seems CMake does not support it (or I could not find a simple solution for it). The solutions I came across suggested that I need to run CMake twice (that is configure and build the specific files in another execution of CMake). Configuring and building in another CMake execution is possible, but to get started (or for the initial version) I just thought it is better to use an environment variable and hard-code the paths and compile everything in the same execution.
If you know any approach of building some specific files with another compiler using CMake, please do let us know! If you know any other solutions or better approaches, please do share them. I will be happy to update. Thanks for looking into this.
There was a problem hiding this comment.
@junghans is this a blocker for you?
This was a new feature that is not enabled by default, so we got something that works at the CI, and the idea was to iterate on this. Now the next step is to not hardwire anything, but make it configurable. I think specifying LFortran's specific cmake options should work.
There was a problem hiding this comment.
It just makes the fedora package build fail, I will submit a PR to fix that.
There was a problem hiding this comment.
@Shaikh-Ubaid I think the right way to do this would be to use ExternalProject_Add().
There was a problem hiding this comment.
I will look into it. Thank you for sharing!
4 participants
towards #3806