Mirror of forum.nim-lang.org

9834 :: nlvm update 202301

• arnetheduck (orginal) [2023-01-20T21:23:15+01:00] view original

  Hey, time for an nlvm update, since I had time over the EOY to push a few updates.

  First and foremost, it must be said that the upstream Nim compiler has gotten a lot more pleasant to use over the past few months thanks to the large amount of bugfixes done in anticipation of 2.0 - many of these have spilled over into the 1.6 branch that nlvm uses making it easier to write a backend and having a better end result - this means that it's also easier to publish patches in the other directions, ie when nlvm is unable to generate code, this is often because of an inconsistency in the AST that the C backend doesn't detect, and with fewer nim bugs in general, it becomes easier to diagnose and upstream even more fixes. Special thanks to everyone that has contributed bugfixes!

  So, with that out of the way, and nlvm being just a side project, a few fun things have happened over the past few months:

  • nlvm is now completely independent of a C compiler environment being installed on the system - with its builtin linker support, it can now produce binaries without gcc/ld/etc being installed at all (of course, if your project uses .c files, you'll still need that stuff - pure nim, pure compilation process)
  • llvm has been updated to 15.0.6 - this came with a major change to how pointers are handled - in particular, pointers are now untyped in the LLVM IR which leads to significant codegen simplifications - it does remove some sanity checking from the IR generation phase, but all in all, this has led to smaller and faster compiles and better codegen.
  • Nim itself has been updated to the latest 1.6 release, bringing with it more fixes than ever
  • Initial support for v2-style strings, seqs and the like has been added - this is the first step towards orc/arc support and eventually v2 support
  • Exception handling saw an overhaul from the initial implementation - many bugs were cleared up, and many bugs in Nim itself were found as a result - in particular, implementing something like finally in llvm requires precise language rules that Nim does not yet have, specially when handling raising inside of finally (or, as v2 would have it, inside destructors) - that said, the dwarf-based exception handling looks pretty neat, and while there are still improvements to make, it should be quite stable
  • The view type / openArray implementation now consistently uses a reifed type, significantly simplifying the implementation

  Up next, I'd probably might revive the just-in-time efforts - llvm continually sees progress on the JIT front and there are now two half-baked PR:s open that probably could be finished in short time, allowing nim to be used without actually creating a binary first - in a perfect world, one would rip out the nim vm and instead use the same llvm IR to drive both binary creation and jit compilation, which also could be combined with stuff like the thinlto compilation cache, enabling the caching of already-optimized function snippets to be used as part of the compilation process - this would require some fairly significant surgery on the nim side however, to make the VM pluggable.

  Other than that, mac support was started in a PR - there are a few bits and pieces to clean up, for which it would need a fresh set of eyes: https://github.com/arnetheduck/nlvm/pull/35 - with the new built-in linking support, another obvious target would be windows where installing C compilers is a pita. On linux, it's pretty nice with the single-file download that includes both compiler and standard library :)

---

• mratsim (orginal) [2023-01-21T01:18:50+01:00] view original

  I'm really confused about ORC, ORCv3 and MCJIT in LLVM but it's surprisingly easy from LLVM IR to create JIT code:

  • emit host machine code: https://github.com/mratsim/constantine/blob/4be89d3/tests/gpu/hello_world_llvm.nim#L11
  • emit Nvidia PTX assembly: https://github.com/mratsim/constantine/blob/4be89d3/tests/gpu/hello_world_nvidia.nim#L121-L139

  with the necessary bindings being only this: https://github.com/mratsim/constantine/blob/4be89d3/constantine/platforms/gpu/bindings/llvm_abi.nim (i.e. no ORC stuff, at least not explicitly)

---

• giaco (orginal) [2023-01-21T07:14:57+01:00] view original

  Looks like black magic to me

  Congrats for the updates!

  I'm looking forward nlvm for wasm targets!

---

• arnetheduck (orginal) [2023-01-21T08:36:28+01:00] view original

  surprisingly easy

  yeah, though once you get into linking libraries it gets a bit hairy ;) that said, most of the code for nlvm is "wiriing" really, they've indeed done a good job to make it just work.

---

• Araq (orginal) [2023-01-21T08:59:06+01:00] view original

  llvm has been updated to 15.0.6 - this came with a major change to how pointers are handled - in particular, pointers are now untyped in the LLVM IR

  Isn't this a major problem for precise alias analysis (AA)? AA is crucial for many optimizations.

---

• arnetheduck (orginal) [2023-01-21T17:20:05+01:00] view original

  Isn't this a major problem for precise alias analysis (AA)? AA is crucial for many optimizations.

  type-based AA needs more specific annotations than the pointers was able to carry, so they were never used for this purpose (they were used for no other purpose than sanity checking apparently, which is why they were removed) - TBAA it's done via special metadata directives both before and after opaque pointers, which nlvm currently doesn't implement (to avoid the strict aliasing bugs that inevitably follow).

---