CODEWITHSUNDEEP
c++modulecompiler-constructionllvm
Matthew Sanders
Matthew Sanders

Reputation: 5065

Creating a modular language in LLVM?

I'm developing a new language in LLVM using the C++ API which compiles down to target the C ABI.

I would like to support modular compilation by allowing end users to build what are effectively static libraries. I noticed the LLVM C++ API has a llvm::Linker class that I can use during compilation to combine source files (llvm::Module), however I wanted to guarantee library compatibility via metadata version numbers or at least the publicly exposed interface between separate compilation runs.

Much of the information available on metadata in LLVM suggest that it should only be used for extended information that would not break correctness when silently removed.

  1. llvm blog
  2. IntrinsicsMetadataAttributes pdf

I wouldn't think this would be a deal breaker as it could be global metadata, but it would be good to get a second opinion on that point.

I also know there is a method in IRReader to parseIRFile so I can load some previously built bc files. I would be curious if it would be reasonable practice to include size and CRC information for comparison when loading these files.

My language has concepts similar to C# including interfaces. I figure I could allow modular compilation by importing/exporting an interface type along with external functions (Much like C++, I don't restrict the language to only methods of classes).

This approach allows me to include language specific information in the interface without needing to encode it in the IR as both the library and the calling code would be required to build with the interface. This again requires the interfaces to be compatible.

One language feature that would require extended information would be named parameters in functions.

My language is very type-safe and also mandates named parameters so there is no predetermined function parameter order. This allows call sites to be more explicit, the compiler to catch erroneous parameter usage, and authors have more liberty in determining default parameters as they are not restricted to the last parameters to the function.

The compiler will need to know names, modifiers, defaults, etc. of these parameters to correctly map calls at compile time, so I figure the interface approach would work well here.

TL;DR

  1. Does LLVM have any predefined facilities for building static libraries?
  2. Is version number, size, and CRC information reasonable use cases for LLVM's metadata?

Upvotes: 3

Views: 663

Answers (1)

Mats Petersson
Mats Petersson

Reputation: 129524

This is probably not QUITE an answer... Or at least not a complete answer.

I like this question, as I'm going to need a solution in the future too (some time in the next few months or years) for my Pascal compiler. It supports "units" which is meant to be a separately compiled object, but currently what I do is simply drag in the source file and compile it into the main llvm::Module - that's neither efficient nor flexible (can't use the linker to choose between the "Linux" and "Windows" version of some code, for example - not that I think there is 5% chance that my compiler will work on Windows without modification anyway...)

However, I'm not sure storing the "object" file as LLVM IR would be the right thing to do. I was thinking that a better way would be to store your AST in some serialized form - then

  1. you don't depend on LLVM versions changing the IR format.
  2. You can add whatever metadata you like. There won't be much difference in generating LLVM-IR from this during your link phase or building the IR at compile and then reading the IR to figure out if the metadata is correct. [The slow part, as you may have already found out, is the optimisation and MC generation, and you'd still have to do that either way]

Like I started out, I'm not sure this is an answer, but it's my thoughts so far on the subject. Now I'll go back to adding debug symbol stuff to my Pascal compiler... Before Christmas, I couldn't see the source in GDB. Now I can step, but no viewing of variables yet...

Upvotes: 3

Related Questions