Page MenuHomePhabricator

[ADT][NFC] Use empty base optimisation in BumpPtrAllocatorImpl
ClosedPublic

Authored by njames93 on Mon, Jan 11, 11:27 AM.

Details

Summary

Most uses of this class just use the default MallocAllocator.
As this contains no fields, we can use the empty base optimisation for BumpPtrAllocatorImpl and save 8 bytes of padding for most use cases.

This prevents using a class that is marked as final as the AllocatorT template argument.
In one must use an allocator that has been marked as final, the simplest way around this is a proxy class.
The class should have all the methods that AllocaterBase expects and should forward the calls to your own allocator instance.

Diff Detail

Event Timeline

njames93 created this revision.Mon, Jan 11, 11:27 AM
njames93 requested review of this revision.Mon, Jan 11, 11:27 AM
Herald added a project: Restricted Project. · View Herald TranscriptMon, Jan 11, 11:27 AM
dblaikie accepted this revision.Mon, Jan 11, 12:10 PM

I think for full generality the standard library does some things to check if a type can be derived from before using it in this way - but we probably don't need all that machinery for LLVM-internal allocator stuff like this?

This revision is now accepted and ready to land.Mon, Jan 11, 12:10 PM

I think for full generality the standard library does some things to check if a type can be derived from before using it in this way - but we probably don't need all that machinery for LLVM-internal allocator stuff like this?

We just have to make sure people don't use an allocator that's defined with the final keyword. I doubt we are going to run into many cases of that.
I have done the template magic to get it make it work if someone wants to use an allocator marked final, should I include it?

I think for full generality the standard library does some things to check if a type can be derived from before using it in this way - but we probably don't need all that machinery for LLVM-internal allocator stuff like this?

We just have to make sure people don't use an allocator that's defined with the final keyword. I doubt we are going to run into many cases of that.
I have done the template magic to get it make it work if someone wants to use an allocator marked final, should I include it?

Probably wouldn't bother - might be worth leaving it here or in the commit message, or in a comment in the code as a "here's how to do it if it turns out someone needs it".

I think for full generality the standard library does some things to check if a type can be derived from before using it in this way - but we probably don't need all that machinery for LLVM-internal allocator stuff like this?

We just have to make sure people don't use an allocator that's defined with the final keyword. I doubt we are going to run into many cases of that.
I have done the template magic to get it make it work if someone wants to use an allocator marked final, should I include it?

Probably wouldn't bother - might be worth leaving it here or in the commit message, or in a comment in the code as a "here's how to do it if it turns out someone needs it".

To make the class work is code than I'd be happy to tack onto the commit message. I'll just make a note in the commit message about it.
Basically just create a class that has an instance of the final Allocator type, then create calls that forward to that instance.

njames93 edited the summary of this revision. (Show Details)Mon, Jan 11, 1:05 PM