[LLVMdev] Two suggestions for improving LLVM error reporting

[Chris Lattner]

On Jan 7, 2010, at 3:52 PM, Talin wrote:

> I realize that LLVM assertion results aren't intended to be seen by end-users ever - they are there to tell front-end developers that they screwed up. Even so, I can think of two things that would make it easier for front-end developers to track down what they did wrong without having to jump into the debugger:

Ok.

> 1) Be able to set a "default module" for dump(). The version of dump() in llvm::Type takes a module parameter, which allows the type to be printed out using the type names registered in that module. However, the various asserts which call dump() or str() don't have a module pointer handy, which causes the type to be printed out as unrecognizable gobbledygook.

Yes, this is lame.

> If there was some way that we could associate either a default module with the LLVMContext - or perhaps register type names with the LLVMContext directly - and have dump() with no arguments use these name mappings - it would make the output more readable. (I kind of like the idea of having a type name dictionary in the LLVM context which is used whenever there is no module pointer handy. For one thing, I could fill it with more readable names than the ones I use in the module's name table.)

My eventual goal (perhaps for LLVM 3.0) is to eliminate our current structural type system altogether.  The benefits are blown away by the costs, eventually we should just fix this design mistake.  In the meantime, I'm not opposed to adding a Module* to VMCore that type dumping defaults to if non-null.

> 2) In the case where type names are available, never print out type names in the form of "%26". I realize that not all types have names - but at least always expand one level, so we can tell whether it's a struct or a pointer or whatever. "{ %32 }" or "%32*" tells me a lot more than just a number by itself. Got a CreateLoad() call that failed? Well if it prints out "{ %32 }" for the assertion argument you instantly know why, even if you don't know what "%32" resolves to.

Sure.  I think the asmwriter already has this capability, it uses it when actually printing out the %42 = type { blah} lines.  It wouldn't do to print out "%42 = type %42" after all :)

> In fact, what would be even cooler would be to set a threshold for the number of levels that were always expanded. I hate trying to read 400-character-long type names, but expanding two or three levels would be quite useful.

:)

-Chris