That looks interesting. They also have a Fortran compiler. Both use the https://github.com/lcompilers/libasr, presumably as a high-level IR. Has anyone checked out its features? Is there any documentation?
That project has received only 20 commits since it was open sourced, with bare minimum readme. Doesn't look like they are interested in exposing it too much for outside use.
We are interested for outside use, but right now we just copy (and sync) the libasr directory with LPython/LFortran manually. All the commits thus go first into either one of the frontends. We decided on this approach as it is currently the easiest for us to manage. Once the frontends are finished, we'll be able to just depend on the libasr as a 3rd party library.
I saw that you also can directly generate x86 assembler from ASR (next to C/C++, Julia, Wasm etc.). Did you do performance comparisons how fast the generated x86 code is e.g. compared to the LLVM backend? That would give indication about the effectiveness of the optimization measures you do on ASR level. With that one could quantify the added value of an LLVM backend and weight it to the costs thereof.
I also noticed that you require C++17 for libasr. What is the main reason for this? How much more difficult would the implementation be if you would e.g. restrict on C++11?
The direct x86 backend (in fact we have two, one is direct ASR->x86, but it only supports a few things so far; the other one is ASR->WASM->x86, which is a lot more complete and even supports 64bits) seems comparable to LLVM without any optimizations. The main added value of LLVM are all the low level optimizations that it can do. Also our LLVM backend is the most complete, it's our main backend. We will eventually catch up with the other backends.
I think we only require C++11, I don't think we use anything newer than that. If we do, it wouldn't be difficult to change. I think we use `std::filesystem`, which is C++17, but if that is a problem, we could add some emulation of this for C++11.
