Displaying 4 results from an estimated 4 matches for "objhead".
Did you mean:
mob_head
2008 Oct 29
2
[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, th...
2008 Oct 29
0
[LLVMdev] maintaining names for types
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... :-)
2008 Oct 29
0
[LLVMdev] maintaining names for types
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
2008 Oct 27
2
[LLVMdev] maintaining names for types
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