diff options
author | Jeremy Morse <jeremy.morse@sony.com> | 2022-03-04 16:39:22 +0000 |
---|---|---|
committer | Jeremy Morse <jeremy.morse@sony.com> | 2022-03-04 17:01:12 +0000 |
commit | 0e96d95d13d9f7b2a96bcaa569ce0a0181a6c7f3 (patch) | |
tree | 15fb1c599aaa9c75a1dd79fbcf6a16ba5c13a503 /lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h | |
parent | 1d1791572cf2172a243ca60bd3ecd7aa2c55e966 (diff) | |
download | llvm-0e96d95d13d9f7b2a96bcaa569ce0a0181a6c7f3.zip llvm-0e96d95d13d9f7b2a96bcaa569ce0a0181a6c7f3.tar.gz llvm-0e96d95d13d9f7b2a96bcaa569ce0a0181a6c7f3.tar.bz2 |
[DebugInfo][InstrRef] Accept register-reads after isel in any block
When lowering LLVM-IR to instruction referencing stuff, if a value is
defined by a COPY, we try and follow the register definitions back to where
the value was defined, and build an instruction reference to that
instruction. In a few scenarios (such as arguments), this isn't possible.
I added some assertions to catch cases that weren't explicitly whitelisted.
Over the course of a few months, several more scenarios have cropped up,
the lastest is the llvm.read_register intrinsic, which lets LLVM-IR read an
arbitary register at any point. In the face of this, there's little point
in validating whether debug-info reads a register in an expected scenario.
Thus: this patch just deletes those assertions, and adds a regression test
to check that something is done with the llvm.read_register intrinsic.
Fixes #54190
Differential Revision: https://reviews.llvm.org/D121001
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h')
0 files changed, 0 insertions, 0 deletions