[PATCH] D31261: [IR] De-virtualize ~Value to save a vptr

Craig Topper via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 22 16:41:41 PDT 2017


How will this interact with this trick http://llvm.org/docs/
ProgrammersManual.html#tagging-considerations where we make an assumption
that the vtable ptr lives at the start of the User object. Is the
assumption now on the Type* that will now be at the start of Value?

~Craig

On Wed, Mar 22, 2017 at 3:21 PM, George Burgess IV via Phabricator via
llvm-commits <llvm-commits at lists.llvm.org> wrote:

> george.burgess.iv added a comment.
>
> Thanks for working on this!
>
> > I think we need some way of checking this at compile time, because
> developers are going to trip over this
>
>
>
>   #define NO_VIRTUALS_ALLOWED(cls) static_assert(!std::is_polymorphic<cls>::value,
> #cls " is not allowed to have virtual methods");
>
>   class Value /* ... */ { /* ... */ };
>   NO_VIRTUALS_ALLOWED(Value);
>
>   class BasicBlock : public Value, /* ... */ { /* ... */ };
>   NO_VIRTUALS_ALLOWED(BasicBlock);
>
> might be a good starting point. Can't think of a way to make it
> automagically apply to subclasses, though.
>
>
>
> ================
> Comment at: include/llvm/IR/DerivedUser.h:28
> +/// Extension point for the Value hierarchy. All classes outside of lib/IR
> +/// that wish to inherit from User should instead inherit from DerivedUser
> +/// instead.
> ----------------
> "instead inherit from DerivedUser instead"?
>
>
> https://reviews.llvm.org/D31261
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170322/99df6eb8/attachment.html>


More information about the llvm-commits mailing list