[LLVMdev] maintaining names for types

[Scott Graham]

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
>
>