diff options
author | Alexis Engelke <engelke@in.tum.de> | 2024-07-30 20:25:18 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-07-30 20:25:18 +0200 |
commit | 9f75270ceb3a0a3fb9b97980031a59652b7d5473 (patch) | |
tree | de4b2f0330f6f20c4a32cbbbcef6a5481bb41777 /lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h | |
parent | d067062a42b0ce591f03c15cb76fe0fb27d1d9c1 (diff) | |
download | llvm-9f75270ceb3a0a3fb9b97980031a59652b7d5473.zip llvm-9f75270ceb3a0a3fb9b97980031a59652b7d5473.tar.gz llvm-9f75270ceb3a0a3fb9b97980031a59652b7d5473.tar.bz2 |
[IR] Add per-function numbers to basic blocks (#101052)
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
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h')
0 files changed, 0 insertions, 0 deletions