I have an implementation of
llvm::StaticVector I’d like to upstream. Essentially, it would be
llvm::SmallVector without the potential to grow beyond inline storage. This saves overhead in the class storage as well as trims any code generated related to growing the heap buffer.
This container is a small piece in a larger vision of seamlessly + efficiently interoperable bitsets with various underlying storage strategies. One flavor of bitset I think would be beneficial is an
llvm::ContiguousBitset class, which is a container adapter that overlays a bitset API on top of any vector-like contiguous container. The
llvm::SmallVector would be an important underlying container for this bitset adapter, but I believe the streamlined
llvm::StaticVector would also be important (think machine model code where resources have compile-time constant limits).
The benefit of using a vector-like container as the underlying storage is that we can track the size separate from the buffer capacity. This means, that if you have a large number of trailing 0s after an operation, you can size the vector down to the last non-zero word and avoid walking those trailing 0s in the future.
In addition, there’s no reason the existing
llvm::BitVector classes can’t be pulled into this common API and all efficiently interoperate with a new bitset concept.
Since I’m new to upstream LLVM (and LLVM in general) I was wondering where to start this process. I figured the
llvm::StaticVector is a good place to start. I do have a patch ready to go… but would be willing to go through an RFC process if necessary.
All of this is something I’ve done behind a company firewall in the past. Just wondering if this is something the community would be interested in.