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

Gabor Greif ggreif at gmail.com
Mon Aug 3 09:36:39 PDT 2009


On Aug 3, 1:17 pm, Nicolas Geoffray <nicolas.geoff... at lip6.fr> wrote:
> 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?

I understood that you are subclassing llvm::Function to carry your
annotations.
When your function objects get serialized, do the annotations appear
in the bitcode?
If not, you have lost them. And when deserializing, do you get back
your defined sublass?
The BitcodeReader might need to be updated to deal with your subclass
otherwise slicing
may happen.

But there is a chance that I understood your solution in the wrong
way :-)

Cheers,

    Gabor

>
> 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-comm... at cs.uiuc.edu
> >http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-comm... at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list