Every basic block that is linked into a function now has a unique number, which can be queried using getNumber(). Numbers are densely allocated, but not re-assigned on block removal for stability. Block numbers are intended to be fairly stable and only be updated when removing a several basic blocks to make sure the numbering doesn't become too sparse. To reduce holes in the numbering, renumberBlocks() can be called to re-assign numbers in block order. Additionally, getMaxBlockNumber() returns a value larger than the largest block number, intended to pre-allocate/resize vectors. Furthermore, this introduces the concept of a "block number epoch" -- an integer that changes after every renumbering. This is useful for identifying use of block numbers after renumbering: on initialization, the current epoch is stored, and on all subsequent accesses, equality with the current epoch can be asserted. I added a validate method to catch cases where something goes wrong, even if I can't really imagine how invalid numbers can occur. But I think it's better to be safe and rule out this potential source of bugs when more things depend on the numbering. Previous discussion in: https://discourse.llvm.org/t/rfc-add-auxiliary-field-for-per-pass-custom-data-to-basicblock/80229
74 KiB
74 KiB