llvm dev - Oct 2008 - [LLVMdev] maintaining names for types

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

On Oct 29, 2008, at 10:50 AM, Scott Graham wrote:
> 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...  :-)

On Wed, Oct 29, 2008 at 4:32 PM, Mike Stump <mrs at apple.com>
wrote:
>
> 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.

scott