[llvm-commits] [llvm] r77706 - in /llvm/trunk: include/llvm/Support/Annotation.h lib/Support/Annotation.cpp

[Nicolas Geoffray]

Hi Gabor,

Gabor Greif wrote:
> Hi Nicolas!
>
> When subclassing LLVM entities you have to be very careful. 

OK.

> Did you
> test whether
> deserialization from bitcode create the right subclass?
>
>   

I've just tested. Serialization of a llvm::Function subclass works fine. 
Deserialization creates a llvm::Function, as expected. Where can there 
be a problem?

Thanks for the warning!
Nicolas

> Cheers,
>
>     Gabor
>
> On Aug 3, 12:14 pm, Nicolas Geoffray <nicolas.geoff... at lip6.fr> wrote:
>   
>> Hi again Dan,
>>
>>
>>
>> Nicolas Geoffray wrote:
>>     
>>> Hi Dan,
>>>       
>>> Dan Gohman wrote:
>>>       
>>>> Author: djg
>>>> Date: Fri Jul 31 13:36:25 2009
>>>> New Revision: 77706
>>>>         
>>>> URL:http://llvm.org/viewvc/llvm-project?rev=77706&view=rev
>>>> Log:
>>>> Remove Annotation.h, which is no longer used in the LLVM tree.
>>>>         
>>> Another way for me is to derive the llvm::Function class, add the
>>> information in the new class and always create this new class instead of
>>> llvm::Function. Do you know if that won't mess with the llvm passes?
>>>       
>> Just to let you know that creating a derive class of llvm::Function
>> works fine in VMKit. All that is needed is to set the llvm::Function
>> constructor to protected instead of private.
>>
>> So I just wanted to make sure creating a derive class of llvm::Function
>> won't break any llvm assumptions. Otherwise, I'll commit the private -->
>> protected patch.
>>
>> Thanks,
>> Nicolas
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-comm... at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>     
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>