Nothing grand to report on the nlvm front, but it did get a bump for both nim (1.2.18) and llvm (14.0.0).
Both are nice improvements - many important nim bugs have been fixed resulting in a better quality nlvm as well - llvm on the other hand comes with a new optimization pass manager that has yet to be enabled, but likely will improve performance - that said, I threw in some codegen improvements based on the llvm IR linting tool as preparation. If you're interested in how LLVM optimizes code in general, this is a good read.
While looking at this, some long-standing bugs were fixed as well - const table initializers now work, several weird codegen issues in json were fixed and over-all, this is a nice solid release.
In the meantime, @Vindaar took some time to bump and refresh the JIT branch to OrcV2: this is fun stuff :) https://github.com/arnetheduck/nlvm/pull/31 - progress on this front is always welcome - there's a lot of good potential there..
Also, Nim 1.6, with its most recent bugfix releases, is nearing the point where it successfully can compile Nimbus - this is good news for nlvm as this is the blocker for moving nlvm to target Nim 1.6.
Do you have any return on experience on nlvm vs classic gcc/compilation?
Pragmatically, is there any big difference in performance, memory usage, C/C++ interop (FFI)? How is multithread ing? How is async?
Good questions, but I haven't measured or paid much attention to performance mainly because it has a fairly trivial information-theoretic answer: "equal or faster" - ie there's nothing that nlvm can't do that nim-via-c can (assuming clang as the c compiler, which compiles to llvm ir just like nlvm, but with an extra translation step), but there are things that nlvm can do that C can't (because of UB and limitations in C causing information to be lost in translation).
I look at its utility first and foremost from a UX and simplicity perspective, where there's fewer moving parts (single compiler does everything from source code to executable), better debugging support (native dwarf), better static analysis tools, single binary distribution on all platforms, VM can run the same bytecode as is used for the final binary (and can be optimized) meaning fewer compile-time bugs / issues, native WASM support, no issues with outdated C compilers or dialects, etc.
That said, if performance is of interest, it's an underserved area in nlvm in general - it's fast enough, and binaries are _generally a little bit faster already without having invested much time in performance - also, lots of low-hanging fruit available, all the way from generating better code, tuning the optimization passes for Nim specifically to exploiting information nlvm has about memory allocation, aliasing etc to make better use of memory and help the GC - because there's one step fewer between you and the optimizer, it's easier to control too.
The biggest difference in FFI is that nlvm does not use C header files at all - this has both advantages and disadvantages: it's easier to use (no mess with header files), but relies on the ABI being accurately described in Nim (sizeof, alignment, member order etc has to match the C code for it to work in nlvm).
Stuff like async will be determined more by the library code than the compiler - if you want better async, chronos implements many optimizations that have bigger impact than the compiler does. Keep in mind that "half" of nlvm is the same as upstream nim: parsing, sem analysis, closure iterator transforms etc is done before the llvm part kicks in: the potential that nlvm has is that it can describe the code that it's given in the native lanague of the other half of the compiler.
There would be two stages for getting things to work - the first stage is to get nlvm itself to compile on windows - this should be trivial - it's a matter of fixing the build scripts to download the windows libraries of llvm instead of ubuntu, then make some trivial adjustments to the linking process.
The second part involves getting compiled applications work and run - this is .. "medium" - it's more onerous than difficult really:
Everything else "should" work as-is (codegen, optimization etc) - happy to help figure things out.