Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Complete Guide to LLVM for Programming Language Creators

mukulrathi.co.uk

Post reply on HN
Print view View original

21–30 of 47 posts

Re: A Complete Guide to LLVM for Programming Language Creators

#21

Post by vnorilo »

dbcurtis wrote: post #11
finiteloop wrote: post #7

As someone who writes a lot of toy languages, I made this scaffolding for a LLVM-based compiler: https://github.com/finiteloop/compiler It uses Bison and Flex for parsing and lexing unlike this post, but may be a useful starting point for those building their own toy languages.

Doesn’t the LLVM API go through breaking changes fairly often? How do you track all that and keep your sanity?

I've been updating a small codegen since the 3.x days. There have been many API changes with major versions. That said, I always found it pretty easy to implement the changes (something like a workday for my ~10k LLVM-interfacing LoC), and the changes tend to be such that once you get it to compile again, it just works as before.

I think LLVM is an excellent demonstration of how to design and implement big systems well in C++, and as a part of that, they also do breaking changes pretty well.

Re: A Complete Guide to LLVM for Programming Language Creators

#24

Post by RealityVoid »

ithkuil wrote: post #23

Does anybody know a good resource like this but for writing backends for a new cpu ISA?

I would like to know this as well. I mostly work with Renesas RH850 cores and was interested to be able to compile rust for them, but there is no v850 backend, sadly. Was considering fiddling with it, but couldn't figure out how.

I also hate the proprietary compilers for this arch, since they are sooo slooow (maybe for good reason, but I have no comparison point) and their licensing method just annoys me.

Re: A Complete Guide to LLVM for Programming Language Creators

#25

Post by broken_symlink »

jws wrote: post #19
ufo wrote: post #5

A question for the LLVM experts here: In the past when I've looked at LLVM from a distance, the biggest stumbling block I found were that it's written in C++ , which isn't the language I'm using for my frontend. How important is the C++ API in practice? Are the bindings for other languages usable? Is it possible to have my frontend emit LLVM IR in a text format, similarly to how you can feed assembly language source…

I emit LLVM IR as text in my compiler. It’s painless, almost. Some points off the top of my head… - I started out just printing strings, but found I wanted a bit more structure so I wrote a dozen or so functions to do the printing. Things at the level of call(name,rags). All make a single line of IR. It helps keep the typos down. - just run your IR through clang to compile it. It has good enough error messages that y…

Can you print variables in lldb with the debug information?

One compiler that I use which emits llvm ir added support for debug information recently and its now possible to set breakpoints in gdb but you can't print out any stack variables or anything so its not useful other than figuring out which code paths execute.

I'd like to learn more about this. Maybe contribute to the compiler and fix this issue.

Re: A Complete Guide to LLVM for Programming Language Creators

#26

Post by tijsvd »

ufo wrote: post #5

A question for the LLVM experts here: In the past when I've looked at LLVM from a distance, the biggest stumbling block I found were that it's written in C++ , which isn't the language I'm using for my frontend. How important is the C++ API in practice? Are the bindings for other languages usable? Is it possible to have my frontend emit LLVM IR in a text format, similarly to how you can feed assembly language source…

I've had success with the llvmlite Python binding. It has a Python-native utility to help build the intermediate code, and then it internally emits text and uses the llvm C api for codegen.

Both the text format and the C api are alledgedly more stable than the C++ api, so this may be a usable pattern in general. The text format is very well documented in my experience.

One downside to using text is an extra emit-and-parse-back step, but unless your code is huge, it's more than fast enough (and it falls away against optimization anyway).

Re: A Complete Guide to LLVM for Programming Language Creators

#28

Post by ritter2a »

mhh__ wrote: post #8
ufo wrote: post #5

A question for the LLVM experts here: In the past when I've looked at LLVM from a distance, the biggest stumbling block I found were that it's written in C++ , which isn't the language I'm using for my frontend. How important is the C++ API in practice? Are the bindings for other languages usable? Is it possible to have my frontend emit LLVM IR in a text format, similarly to how you can feed assembly language source…

I would avoid any text, but LLVM has mature bindings in ocaml and Haskell, for example. The textual representation isn't stable IIRC, and it adds a step in between you and your already lumbering backend. Ultimately the C++ API isn't too difficult to use but LLVM mandates a fairly hardcore level of C++ knowledge to play with it's internals. Quick Tip: if you're thinking "Holy shit how do I get from [complicated] all t…

Regarding interface stability: Indeed, the textual representation is not stable, things like added types in the representation of some instructions can happen when upgrading to a new version. However, to be entirely honest, in the last few years of updating LLVM-based research tools to newer LLVM versions, changes in the C++ API that required me to (sometimes just slightly) change my code happened a lot more often than changes in the textual representation...

Re: A Complete Guide to LLVM for Programming Language Creators

#29

Post by RicardoLuis0 »

TazeTSchnitzel wrote: post #2

> LLVM IR looks like a more readable form of assembly I think assembly is more readable than the dumped LLVM IR output of a real compiler… Anyway, that was a good overview of how to build simple LLVM IR. :)

I'd say readability of dumped IR would be on par with dumped assembly from a compiler for readability, but hand-written LLVM IR has the potential to be quite a lot more readable than hand-written assembly

Re: A Complete Guide to LLVM for Programming Language Creators

#30

Post by exDM69 »

ufo wrote: post #5

A question for the LLVM experts here: In the past when I've looked at LLVM from a distance, the biggest stumbling block I found were that it's written in C++ , which isn't the language I'm using for my frontend. How important is the C++ API in practice? Are the bindings for other languages usable? Is it possible to have my frontend emit LLVM IR in a text format, similarly to how you can feed assembly language source…

> Are the bindings for other languages usable?

Yes, I've done several compiler projects using Haskell and LLVM.

That said, not all the bindings were always maintained and up to date and together with LLVM's lack of API stability, there was a significant amount of churn work related to updating from one LLVM version to another. I had to build and install an older version of LLVM that would work with the bindings, several times.

Note: this was years ago, situation may have improved.

I understand that LLVM API doesn't change significantly between versions any more so the work required to update the bindings to a newer version shouldn't be huge for the maintainers of the bindings. But for an end user like me there was quite a lot of manual steps to get my project and the dependencies building.

There's always the option of emitting LLVM IR by writing text, but that doesn't give you the ability to do JITting and a REPL and so on.

Post reply on HN