My top 5 LLVM wishes

I've been using LLVM for quite a few months now, as part of writing a compiler for a statically typed programming language. During this time, I've been keeping a list of improvements I would like to see in LLVM.

Note that most of the items on this list are issues that I have posted here before. I thought it might be a useful bit of feedback to summarize just the most important, most persistent, or most vexing unsolved issues that I have encountered.

1) The number one thing I would like for LLVM is a single-step debugger for IR. In other words, something like lli, that operates directly on bitcode files, but allows executing instructions one at a time.

Trying to find an error in an IR program is quite difficult. Running lli under gdb works, but it's difficult to make sense of the internal data structures of the interpreter. Compiling to native assembly code is another option, however gdb is fairly painful to use if you don't have source-level debugging information working in your compiler.

I would even settle for a way for lli to print each instruction before it is executed, so that I could at least know where in the program a crash occurred.

2) More informative error messages in the libraries. The function verifier is particularly bad at this - it will throw an assertion or print an error, but it won't tell you where in your code the error occurred or even much about it. Similarly, lli handles errors mostly by crashing. While it does give a stack dump, the stack dump isn't useful if figuring out where your IR code went wrong.

3) A way to put a sentinel value at the end of an appending linkage section. As far as I can tell, appending linkage isn't very useful with the stock llvm linker, because you have no way to tell how long the section is, and thus no way to process it. If there was some way to place a sentinel value at the end, then at least you could discover the size by scanning the array. Perhaps an attribute like "append last" which would cause the specified definition to be appended after all other definitions?

4) The exact same set of features and semantics should be available regardless of whether you are running in the interpreter, the JIT or native code. Currently, things like unwind and thread local vars are only available in some contexts and not others.

5) A way to tell the optimizer whether we are compiling an application or a library - specifically, I'd like to be able to tell it to prune all globals not reachable from 'main'. (It currently does this in llc, but I'd like to be able to operate on a bitcode file.)

(For one thing, such a capability would make it much easier to create 'minimal' code samples for reporting bugs! :slight_smile:

-- Talin

5) A way to tell the optimizer whether we are compiling an application
or a library - specifically, I'd like to be able to tell it to prune all
globals not reachable from 'main'. (It currently does this in llc, but
I'd like to be able to operate on a bitcode file.)

I think the internalize pass does exactly this, you could just run opt
-internalize on your bitcode before running other optimizations to get this
effect?

Gr.

Matthijs