Displaying 8 results from an estimated 8 matches for "upreferences".
Did you mean:
preferences
2005 Mar 21
2
[LLVMdev] Recursive Types using the llvm support library
On Sun, 20 Mar 2005, John Carrino wrote:
> 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
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
On Sun, Mar 20, 2005 at 07:01:55PM -0600, Chris Lattner wrote:
> On Sun, 20 Mar 2005, John Carrino wrote:
>
> >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
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 and...
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.
>
>-Chri...