[llvm] Introduce paged vector (PR #66430)

[Vassil Vassilev via llvm-commits]

================
@@ -0,0 +1,323 @@
+//===- llvm/ADT/PagedVector.h - 'Lazyly allocated' vectors --------*- C++
+//-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file defines the PagedVector class.
+//
+//===----------------------------------------------------------------------===//
+#ifndef LLVM_ADT_PAGEDVECTOR_H
+#define LLVM_ADT_PAGEDVECTOR_H
+
+#include "llvm/ADT/PointerIntPair.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/iterator_range.h"
+#include "llvm/Support/Allocator.h"
+#include <cassert>
+#include <vector>
+
+namespace llvm {
+/// A vector that allocates memory in pages.
+///
+/// Order is kept, but memory is allocated only when one element of the page is
+/// accessed. This introduces a level of indirection, but it is useful when you
+/// have a sparsely initialised vector where the full size is allocated upfront.
+///
+/// As a side effect the elements are initialised later than in a normal vector.
+/// On the first access to one of the elements of a given page all, the elements
+/// of the page are initialised. This also means that the elements of the page
+/// are initialised beyond the size of the vector.
+///
+/// Similarly on destruction the elements are destroyed only when the page is
+/// not needed anymore, delaying invoking the destructor of the elements.
+///
+/// Notice that this does not have iterators, because if you have iterators it
+/// probably means you are going to touch all the memory in any case, so better
+/// use a std::vector in the first place.
+template <typename T, size_t PageSize = 1024 / sizeof(T)> class PagedVector {
+  static_assert(PageSize > 1, "PageSize must be greater than 0. Most likely "
+                              "you want it to be greater than 16.");
+  // The actual number of element in the vector which can be accessed.
+  size_t Size = 0;
+
+  // The position of the initial element of the page in the Data vector.
+  // Pages are allocated contiguously in the Data vector.
+  mutable SmallVector<T *, 0> PageToDataPtrs;
+  // Actual page data. All the page elements are added to this vector on the
+  // first access of any of the elements of the page. Elements default
+  // constructed and elements of the page are stored contiguously. The order of
+  // the elements however depends on the order of access of the pages.
+  PointerIntPair<BumpPtrAllocator *, 1, bool> Allocator;
+
+  constexpr static T *InvalidPage = nullptr;
+
+public:
+  using value_type = T;
+
+  /// Default constructor. We build our own allocator and mark it as such with
+  /// `true` in the second pair element.
+  PagedVector() : Allocator(new BumpPtrAllocator, true) {}
+  PagedVector(BumpPtrAllocator *A) : Allocator(A, false) {
+    assert(A != nullptr && "Allocator cannot be null");
+  }
+
+  ~PagedVector() {
+    clear();
+    // If we own the allocator, delete it.
+    if (Allocator.getInt())
+      delete Allocator.getPointer();
+  }
+
+  /// Look up an element at position `Index`.
+  /// If the associated page is not filled, it will be filled with default
+  /// constructed elements. If the associated page is filled, return the
+  /// element.
+  T &operator[](size_t Index) const {
+    assert(Index < Size);
+    assert(Index / PageSize < PageToDataPtrs.size());
+    T *&PagePtr = PageToDataPtrs[Index / PageSize];
+    // If the page was not yet allocated, allocate it.
+    if (PagePtr == InvalidPage) {
+      T *NewPagePtr = Allocator.getPointer()->template Allocate<T>(PageSize);
+      // We need to invoke the default constructor on all the elements of the
+      // page.
+      for (size_t I = 0; I < PageSize; ++I)
+        new (NewPagePtr + I) T();
+
+      PagePtr = NewPagePtr;
+    }
+    // Dereference the element in the page.
+    return *((Index % PageSize) + PagePtr);
+  }
+
+  /// Return the capacity of the vector. I.e. the maximum size it can be
+  /// expanded to with the resize method without allocating more pages.
+  [[nodiscard]] size_t capacity() const {
+    return PageToDataPtrs.size() * PageSize;
+  }
+
+  /// Return the size of the vector. I.e. the maximum index that can be
+  /// accessed, i.e. the maximum value which was used as argument of the
+  /// resize method.
+  [[nodiscard]] size_t size() const { return Size; }
+
+  /// Resize the vector. Notice that the constructor of the elements will not
+  /// be invoked until an element of a given page is accessed, at which point
+  /// all the elements of the page will be constructed.
+  ///
+  /// If the new size is smaller than the current size, the elements of the
+  /// pages that are not needed anymore will be destroyed, however, elements of
+  /// the last page will not be destroyed.
+  ///
+  /// For these reason the usage of this vector is discouraged if you rely
+  /// on the construction / destructor of the elements to be invoked.
+  void resize(size_t NewSize) {
+    if (NewSize == 0) {
+      clear();
+      return;
+    }
+    // Handle shrink case: destroy the elements in the pages that are not
----------------
vgvassilev wrote:

Do we really want to support shrinking? I mean I understand the general usecase but if we "sell" this data structure as a performance optimization applicable in cases when we know the container size (but we do not know the memory access pattern and we only assume it will be sparse). I'd think that we want to complain if people try to use it outside of this use-case...

https://github.com/llvm/llvm-project/pull/66430