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

Craig Topper via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 22 19:34:14 PDT 2017


Due to using PointerIntPair and PointerLikeTypeTraits we're really using
bit 2 on 64-bit builds. So we're assuming vtables have 8 byte alignment


On Wed, Mar 22, 2017 at 5:22 PM Reid Kleckner <rnk at google.com> wrote:

> On Wed, Mar 22, 2017 at 4:41 PM, Craig Topper <craig.topper at gmail.com>
> wrote:
>
> 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?
>
>
> Yes, I think you're right. This code here reinterprets the vptr (or Type*
> now) as a UserRef, checks the bottom bit, and if it is unset, reinterprets
> it as a User. Otherwise, it masks the bit and loads from it to get back to
> the User:
>
> User *Use::getUser() const {
>   const Use *End = getImpliedUser();
>   const UserRef *ref = reinterpret_cast<const UserRef *>(End);
>   return ref->getInt() ? ref->getPointer()
>                        : reinterpret_cast<User *>(const_cast<Use *>(End));
> }
>
> So, we were relying on vtables being two byte aligned. Now we're relying
> on Types being at least two byte aligned.
>
> We should... clean this up at some point to operate within the language.
> It shouldn't be hard.
>
-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170323/963f5838/attachment.html>


More information about the llvm-commits mailing list