[LLVMdev] My top 5 LLVM wishes

Talin viridia at gmail.com
Thu Jun 12 01:48:17 PDT 2008

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

More information about the llvm-dev mailing list