Displaying 8 results from an estimated 8 matches for "upreference".
Did you mean:
preference
2005 Mar 21
2
[LLVMdev] Recursive Types using the llvm support library
...t;>>
>> I create test program and assert failed in it:
>>
>> { \2 *, sbyte * }
>
> How do I decode the \2 in this? I am creating types through this
> interface and I get quite a mess seen below. And this is relatively
> simple. Any ideas?
"\2" is an upreference, which refers to a containing type. For example,
this type:
\1*
Is a pointer to pointer to pointer to pointer.... In "{\2*}", the
upreference refers to the structure type, not the pointer, with \4, it
means go 4 types up etc.
In practice, this is leads to a horrible mess, as you...
2010 Jan 09
3
[LLVMdev] Two suggestions for improving LLVM error reporting
On Saturday 09 January 2010 06:11:03 Chris Lattner wrote:
> My eventual goal (perhaps for LLVM 3.0) is to eliminate our current
> structural type system altogether. The benefits are blown away by the
> costs, eventually we should just fix this design mistake. In the meantime,
> I'm not opposed to adding a Module* to VMCore that type dumping defaults to
> if non-null.
Can you
2005 Mar 21
0
[LLVMdev] Recursive Types using the llvm support library
...ogram and assert failed in it:
> >>
> >>{ \2 *, sbyte * }
> >
> >How do I decode the \2 in this? I am creating types through this
> >interface and I get quite a mess seen below. And this is relatively
> >simple. Any ideas?
>
> "\2" is an upreference, which refers to a containing type. For example,
> this type:
>
> \1*
>
> Is a pointer to pointer to pointer to pointer.... In "{\2*}", the
> upreference refers to the structure type, not the pointer, with \4, it
> means go 4 types up etc.
>
> In practi...
2005 Mar 21
0
[LLVMdev] Recursive Types using the llvm support library
On Wed, Mar 09, 2005 at 04:05:32PM +0300, Vladimir Merzliakov wrote:
> >>Is assert(!NewSTy->isAbstract()) must pass after this line?
> >
> >In this case, yup.
> >
> I create test program and assert failed in it:
>
> { \2 *, sbyte * }
How do I decode the \2 in this? I am creating types through this
interface and I get quite a mess seen below. And this is
2010 Jan 09
0
[LLVMdev] Two suggestions for improving LLVM error reporting
...ot get implicitly unioned with "i32***". This would also eliminate the current complexity forming circular types, make many frontends simpler etc. It would mean that a cyclic type would be *required* to go through a named type though.
>>
>> It would also allow elimination of upreferences, PATypeHolder, PATypeHandle, etc. It would also eliminate the frequent confusion around "my function should take a %foo*, it the IR dump shows it as %bar*" (because they have the same type structure).
>>
>> OTOH, it would mean that we couldn't have the totally awesome an...
2005 Mar 09
4
[LLVMdev] Recursive Types using the llvm support library
----- Original Message -----
From: "Chris Lattner" <sabre at nondot.org>
To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
Sent: Tuesday, March 08, 2005 6:31 PM
Subject: Re: [LLVMdev] Recursive Types using the llvm support library
> On Tue, 8 Mar 2005, Vladimir Merzliakov wrote:
>
>>>> An example where something really simple like the
2005 Jun 06
1
[LLVMdev] one question about up reference
hi,
I have one question about up reference, why use \nested_level_count in type description.
and have to handle it in HandleUpRefs() (AsmParser/llvmAsmParser.y) ,
why not just insert type name and return in calcTypeName() (AsmWriter.cpp) ;
As you mention in "How to build recursively type" ,
%mylist = type { %mylist*, int } is accepted .
Is it neccessary to use
2005 Jun 07
0
[LLVMdev] one question about up reference
...t;> As you mention in "How to build recursively type" ,
>>
>> %mylist = type { %mylist*, int } is accepted .
>>
>> Is it neccessary to use \nested_level_count ?
>>
>> I'm very thankful if you can give me some C code example to show it .
>
>Upreferences are used when the symbol table is stripped. The above type
>can be written like this without a name:
>
> {\2*, int}
>
>This is important because LLVM does not require every type to have a name,
>but I wouldn't recommend language front-ends to generate these.
>
>-Chr...