diff options
| author | Eli Friedman <efriedma@quicinc.com> | 2022-08-16 16:15:44 -0700 |
|---|---|---|
| committer | Eli Friedman <efriedma@quicinc.com> | 2022-08-16 16:15:44 -0700 |
| commit | cfd2c5ce580fce744f6fd6ba34e869cab05e94c3 (patch) | |
| tree | ca1395331cdc448d042dd192c0856e7a9c141943 /lldb/source/Commands/CommandObjectThread.cpp | |
| parent | d9198f64d9be149acdad109cd053b6acdd9635d2 (diff) | |
| download | llvm-cfd2c5ce580fce744f6fd6ba34e869cab05e94c3.zip llvm-cfd2c5ce580fce744f6fd6ba34e869cab05e94c3.tar.gz llvm-cfd2c5ce580fce744f6fd6ba34e869cab05e94c3.tar.bz2 | |
Untangle the mess which is MachineBasicBlock::hasAddressTaken().
There are two different senses in which a block can be "address-taken".
There can be a BlockAddress involved, which means we need to map the
IR-level value to some specific block of machine code. Or there can be
constructs inside a function which involve using the address of a basic
block to implement certain kinds of control flow.
Mixing these together causes a problem: if target-specific passes are
marking random blocks "address-taken", if we have a BlockAddress, we
can't actually tell which MachineBasicBlock corresponds to the
BlockAddress.
So split this into two separate bits: one for BlockAddress, and one for
the machine-specific bits.
Discovered while trying to sort out related stuff on D102817.
Differential Revision: https://reviews.llvm.org/D124697
Diffstat (limited to 'lldb/source/Commands/CommandObjectThread.cpp')
0 files changed, 0 insertions, 0 deletions