[libc-commits] [libc] [libc] Add aligned_alloc (PR #96586)
Paul Kirth via libc-commits
libc-commits at lists.llvm.org
Tue Jun 25 10:03:33 PDT 2024
================
@@ -357,6 +392,58 @@ void Block<OffsetType, kAlign>::free(Block *&block) {
merge_next(block);
}
+template <typename OffsetType, size_t kAlign>
+bool Block<OffsetType, kAlign>::can_allocate(size_t alignment,
+ size_t size) const {
+ if (usable_space_is_aligned(alignment) && inner_size() >= size)
+ return true; // Size and alignment constraints met.
+
+ // Either the alignment isn't met or we don't have enough size.
+ // If we don't meet alignment, we can always adjust such that we do meet the
+ // alignment. If we meet the alignment but just don't have enough size. This
+ // check will fail anyway.
+ size_t adjustment = extra_space_for_adjustment(alignment);
+ if (inner_size() >= size + adjustment)
+ return true;
+
+ return false;
+}
+
+template <typename OffsetType, size_t kAlign>
+void Block<OffsetType, kAlign>::allocate(Block *&block, size_t alignment,
+ size_t size, Block *&new_prev,
+ Block *&new_next) {
----------------
ilovepi wrote:
do you think this API would make more sense if you passed in a struct instead of the pointer references?
```suggestion
struct block_info{ Block* block, Block* prev, Block* next};
void Block<OffsetType, kAlign>::allocate(BlockInfo &block_info, size_t alignment,
size_t size) {
```
I find the mutable references to pointers to make for an odd API, and this reads a bit more naturally to me.
Feel free to disregard this though, since this comes down to style, and it could be this API is this shape for another reason.
https://github.com/llvm/llvm-project/pull/96586
More information about the libc-commits
mailing list