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! :)
-- Talin