I'm working on switching from generating textual .ll files in my front
end to using the llvm-c IR builder API instead.
One thing that I really miss is that when I dump() to a .ll file for
debugging, the type names are worse than useless, because many types
have been merged with unrelated types that happen to have the same
shape. This becomes very confusing when trying to map back to the
original source code's types in large .ll files.
Can anyone suggest any workarounds for this? The best I came up with
was appending an arbitrary length vector to all type declarations to
make them all unique, but then of course the code's wrong.
I run into this problem as well. However, given the way LLVM represents types and their names, there is not an easy solution to this problem. I don’t know of any real workaround that will not change the semantics of the code.
Shucks, I figured as much, but I was hoping...
Relatedly, it would be convenient to have a way to reliably influence
which name gets chosen for the merged type. If I could at least have
things like "%ObjHeader" not turn into
"%SomeUserCodeType_NestedUserClass_Blorp", that would go a long way.
What rule would you use to pick between the two? min(strlen)? First? Last? min(wc -w)? If you had a way to pick, people might go along with it...
But, but, I just like to "complain", not "solve".
I'd personally go with "First", as I think registering the system's
types at startup and having them persist would make the most sense.
I'm not too clear where the might happen as far as the Module's
TypeSymbolTable and maybe fillTypeNameTable go.