4 ms·

I would really like to see more discussions about the difficulties using LLVM can create for smaller language projects. The entire PL ecosystem is hyped up to r

I would really like to see more discussions about the difficulties using LLVM can create for smaller language projects. The entire PL ecosystem is hyped up to revolve around the project, but rarely do you see language designers and solo/small group devs talk specifically about problems relying on LLVM. The history section of XL’s page cites non-commitment to code compatibility between releases as their big struggle, which is a change from the more common complaints of inherent complexity and compilation time. I’d love to see more discussion of this, and maybe, see a focus on smaller backends and code generation tools for compilation, like QBE. Anyone with recommendations for reading would be welcome to dump those here.

c3d 3y ago
I specifically addressed some of these topics in this talk: https://www.youtube.com/watch?v=Xzo7GIoDgAo https://www.youtube.com/watch?v=Xzo7GIoDgAo
Arelius 3y ago
For sure this. I have a little compiler from 10+ years ago I was working on. And I recall after I had put it down, and tried picking it back up just maybe a year later(?) The interfaces I was using in llvm all changed. It really took the wind out of my sails for jumping back in.
c3d 3y ago
I realized I forgot to share my most memorable piece of code ever: llvm-crap (Compatibility Restoration Adaptive Protocol) https://github.com/c3d/xl/blob/master/src/llvm-crap.h https://github.com/c3d/xl/blob/master/src/llvm-crap.h
- c3d 3y ago
  The really ugly stuff is here: https://github.com/c3d/xl/blob/master/src/llvm-crap.cpp https://github.com/c3d/xl/blob/master/src/llvm-crap.cpp
sixthDot 3y ago
From what I can read the author got really unlucky with some kind of radical API changes. Maybe at that time the LLVM team was a bit less serious with deprecations ? I use LLVM since v9, nowadays I'm stuck on v15 (that's not because of LLVM btw). Between the two versions there's been a radical change too, i.e "opaque pointers", but the transition was rather smooth as we were provided, for a long time, the two versions of the functions affected by the change. Maybe the LLVM team got more serious since the author experienced the said difficulties ? Other thing I note is that the author uses the CPP API. I use the C one which exposes only a high-level subset of the CPP one. This encourages a saner use of LLVM, a more concrete separation between the front-end and the mid-end, although sometimes there are limitations. A simple example of what encourages the C API, especially since opaque ptrs are added, is not to rely on LLVM to retrieve the IR type of an IR value. That should always be done using the AST, eg with an `.ir` field in your nodes. Another one I remark, after a brief overview of LLVM-CRAP, is that the author had to change the internal data structure used, depending on the LLVM version [0]. Using the C API that would never had happened. The C API essentially allows to create block refs, instructions refs, value refs, type refs, contexts. Then you choose the containers you want to use to hold them. No need to switch to another stdcpp one, even if internally LLVM does so. [0]: https://github.com/c3d/xl/blob/master/src/llvm-crap.cpp#L265 https://github.com/c3d/xl/blob/master/src/llvm-crap.cpp#L265

c3d 3y ago

I specifically addressed some of these topics in this talk: https://www.youtube.com/watch?v=Xzo7GIoDgAo https://www.youtube.com/watch?v=Xzo7GIoDgAo

Arelius 3y ago

For sure this. I have a little compiler from 10+ years ago I was working on. And I recall after I had put it down, and tried picking it back up just maybe a year later(?) The interfaces I was using in llvm all changed. It really took the wind out of my sails for jumping back in.

c3d 3y ago

I realized I forgot to share my most memorable piece of code ever: llvm-crap (Compatibility Restoration Adaptive Protocol) https://github.com/c3d/xl/blob/master/src/llvm-crap.h https://github.com/c3d/xl/blob/master/src/llvm-crap.h

c3d 3y ago
The really ugly stuff is here: https://github.com/c3d/xl/blob/master/src/llvm-crap.cpp https://github.com/c3d/xl/blob/master/src/llvm-crap.cpp

sixthDot 3y ago

From what I can read the author got really unlucky with some kind of radical API changes. Maybe at that time the LLVM team was a bit less serious with deprecations ? I use LLVM since v9, nowadays I'm stuck on v15 (that's not because of LLVM btw). Between the two versions there's been a radical change too, i.e "opaque pointers", but the transition was rather smooth as we were provided, for a long time, the two versions of the functions affected by the change. Maybe the LLVM team got more serious since the author experienced the said difficulties ? Other thing I note is that the author uses the CPP API. I use the C one which exposes only a high-level subset of the CPP one. This encourages a saner use of LLVM, a more concrete separation between the front-end and the mid-end, although sometimes there are limitations. A simple example of what encourages the C API, especially since opaque ptrs are added, is not to rely on LLVM to retrieve the IR type of an IR value. That should always be done using the AST, eg with an `.ir` field in your nodes. Another one I remark, after a brief overview of LLVM-CRAP, is that the author had to change the internal data structure used, depending on the LLVM version [0]. Using the C API that would never had happened. The C API essentially allows to create block refs, instructions refs, value refs, type refs, contexts. Then you choose the containers you want to use to hold them. No need to switch to another stdcpp one, even if internally LLVM does so. [0]: https://github.com/c3d/xl/blob/master/src/llvm-crap.cpp#L265 https://github.com/c3d/xl/blob/master/src/llvm-crap.cpp#L265