Hi 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. thanks, scott
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. - Daniel On Mon, Oct 27, 2008 at 4:42 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote:> Hi > > 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. > > thanks, > scott > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081028/a71316ba/attachment.html>
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. scott On Tue, Oct 28, 2008 at 9:16 PM, Daniel Dunbar <daniel at zuster.org> wrote:> 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. > - Daniel > > On Mon, Oct 27, 2008 at 4:42 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote: >> >> Hi >> >> 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. >> >> thanks, >> scott >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >