[LLVMdev] maintaining names for types
sgraham at gmail.com
Wed Oct 29 10:50:28 PDT 2008
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.
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
> - Daniel
> On Mon, Oct 27, 2008 at 4:42 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote:
>> 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.
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev