SIL: add a StackList data structure with zero cost operations. #36819
Conversation
|
@swift-ci test |
A StackList is the best choice for things like worklists, etc., if no random access is needed. Regardless of how large a Stack gets, there is no memory allocation needed (except maybe for the first few uses in the compiler run). All operations have (almost) zero cost. The needed memory is managed by the SILModule. Initially, the memory slabs are allocated with the module's bump pointer allocator. In contrast to bump pointer allocated memory, those slabs can be freed again (at zero cost) and then recycled. StackList is meant to be a replacement for llvm::SmallVector, which needs to malloc after the small size is exceeded. This is more a usability than a compile time improvement. Usually we think hard about how to correctly use an llvm::SmallVector to avoid memory allocations: we chose the small size wisely and in many cases we keep a shared instance of a SmallVector to reuse its allocated capacity. All this is not necessary by using a StackList: no need to select a small size and to share it across usages.
plus: I moved both data structures into a separate header file.
|
@swift-ci smoke test |
|
This appears to be implicated in the failure in https://ci.swift.org/job/oss-swift_tools-R_stdlib-RD_test-simulator/5997/. |
|
@eeckstein do you have a plan for instruction worklists? There's a general purpose |
|
@eeckstein I'm sure this won't be as efficient as the highly optimized SmallVector, but I generally prefer pass-level allocation because I don't need to contort all my pass designs to reuse malloc'd memory and I can move implementation into the .cpp files. |
|
@eeckstein @gottesmm my only real complaint is that discoverability of SIL-specific ADTs is hard. We may need a SIL/Utils header subdirectory |
|
@atrick SILInstructionWorklist is a more high-level data structure for SILCombine. But yes, I'd like to have the same as BasicBlockWorklist for SILNodes (SILValue and instructions) - by doing the same "set" trick as with BasicBlockSet. My motivation for this is mainly to make those data structures available in libswift, where we don't have the LLVM ADTs. |
A StackList is the best choice for things like worklists, etc., if no random access is needed.
Regardless of how large a Stack gets, there is no memory allocation needed (except maybe for the first few uses in the compiler run).
All operations have (almost) zero cost.
The needed memory is managed by the SILModule. Initially, the memory slabs are allocated with the module's bump pointer allocator. In contrast to bump pointer allocated memory, those slabs can be freed again (at zero cost) and then recycled.
StackList is meant to be a replacement for llvm::SmallVector, which needs to malloc after the small size is exceeded.
This is more a usability than a compile time improvement.
Usually we think hard about how to correctly use an llvm::SmallVector to avoid memory allocations: we chose the small size wisely and in many cases we keep a shared instance of a SmallVector to reuse its allocated capacity.
All this is not necessary by using a StackList: no need to select a small size and to share it across usages.