11–20 of 47 posts
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.
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?
If I wanted to target LLVM, why wouldn’t I emit ll or bc files?
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.
https://github.com/empirical-soft/calculANTLR
It uses a C++ port of CPython's ASDL to define the AST.
It’s possible I missed this from the article, since I’m not actually following along, but why do I need to create the custom C++ adapter? The article mentions both ll bc formats, but I don’t see how they are used? If I wanted to target LLVM, why wouldn’t I emit ll or bc files?
It’s possible I missed this from the article, since I’m not actually following along, but why do I need to create the custom C++ adapter? The article mentions both ll bc formats, but I don’t see how they are used? If I wanted to target LLVM, why wouldn’t I emit ll or bc files?
What do you mean by C++ adapter? All the c++ in this post is building the LL files in memory, which can them be persisted to disk or wherever.
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 also know of at least one compiler[2] that actually emits textual IR, and then builds and links .obj files from that with the LLVM toolchain...but I think that's just a bunch of work, would be hard to debug, and generally just a bad idea.
1: https://github.com/chc4/solar/blob/master/src/jit.lua 2: https://github.com/gilzoide/lualvm which I actually had to fork to https://github.com/chc4/lualvm for a small bugfix 3: https://github.com/FeepingCreature/fcc/blob/master/llvmfile.... by 'feepingcreature
Earlier quoted context omitted.
What do you mean by C++ adapter? All the c++ in this post is building the LL files in memory, which can them be persisted to disk or wherever.
Ah I didn’t understand that aspect. So we write the parser in ocaml, then serialize it to protobuf, then consume that from C++ so we can call LLVM’s API to write the expected file format? That still seems needlessly complicated. Is the file format simply too arcane?especially given [0]. [0] https://news.ycombinator.com/item?id=25540637
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 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 you won’t go mad.
- you will need to make a bunch of DI metadata to get debug information into your programs. It took me about 8 hours to get enough that I have line number information and LLDB will show me functions and source lines on a backtrace. I should have done this much earlier than I did. I was getting by with line number comments in my IR, which is simple, but useless if you Give yourself an access violation.
- learn to write little C programs and use clang to emit the IR. This will let you sort out how to do things. The IR manual is good, but there are concepts which are omitted because they were obvious to the authors, but won’t be to you.
- local symbols have to be in strict, ascending, no skipped values numerical order. Screw that. Grab a dollar sign and make your own numeric local-ish symbols and don’t sweat reordering them.
- it doesn’t seem to care what order you emit things in, other than lines in a block of course, so just do what is easy for you.
- get a grip on getelemtptr and phi. The first may not be what you think it is, learn what it is. The second is just part of the magic of SSA.
Earlier quoted context omitted.
Ah I didn’t understand that aspect. So we write the parser in ocaml, then serialize it to protobuf, then consume that from C++ so we can call LLVM’s API to write the expected file format? That still seems needlessly complicated. Is the file format simply too arcane?especially given [0]. [0] https://news.ycombinator.com/item?id=25540637
I see, in this case the author's compiler was written in c++, but you can use ocaml instead to build the IR. There is even a version of their great tutorial series using ocaml you can check out. All the concepts he outlines are the same, just convert the c++ bits to the corresponding ocaml version of the IRBuilder. Then you can go from your language to llvm IR all in ocaml. https://llvm.org/docs/tutorial/OCamlLangImp…