[PATCH] D12455: [IR] Teach `llvm::User` to co-allocate a descriptor.

Pete Cooper via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 2 14:03:32 PDT 2015


pete added a comment.

In http://reviews.llvm.org/D12455#238662, @sanjoy wrote:

> In http://reviews.llvm.org/D12455#238526, @pete wrote:
>
> > This is just a question, not intended to block the commit if someone else gives a LGTM.
> >
> > Have you considered making use of 'hung off uses' instead of adding DescBytes to new?
> >
> > It would take a little work to change 'hung off uses' to actually be 'hung off bytes', and i haven't looked to see how possible that is, but it feels to me like it should be considered.
> >
> > This also has the advantage of moving the desc bytes handling out of new so that all User's don't pay the price for checking them in new, and instead the rare case of meeting extra bytes can get them only on request.
>
>
> Is the only motivation for making the descriptor bytes be hung off
>  that we won't have to check `DescriptorBytes == 0` in `operator new`
>  (I cannot think of anything else that hung off descriptor bytes will
>  help)?
>
> If so, I think there is an easier way to fix this -- I can just
>  overload `operator new` into a version that takes the
>  `DescriptorBytes` argument, and a version that does not.  Most of
>  `User`s will call the latter, and won't have to pay the penalty of
>  checking `DescriptorBytes == 0`.  There will still be the penalty of
>  setting `Obj->HasDescriptor = 0` in the latter, but I'd expect that to
>  be folded into whatever `operator new` does to set
>  `Obj->HasHungOffUses = false`.  Does this sound reasonable to you?


Yeah, that was the only motivation.  Like I said, shouldn't block things if you think it'll be ok.

Saying that, I do prefer your suggestion to overload operator new.  I'd be totally fine with that.

Thanks!


http://reviews.llvm.org/D12455





More information about the llvm-commits mailing list