aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python
diff options
context:
space:
mode:
authorPhilip Reames <listmail@philipreames.com>2021-12-17 08:32:43 -0800
committerPhilip Reames <listmail@philipreames.com>2021-12-17 09:02:03 -0800
commit33cbaab1416b234d5a08b41e3110d64a00b0651c (patch)
tree931b49c52d2a72b5f1d3df4f634f59e821d8e284 /lldb/source/Plugins/ScriptInterpreter/Python
parent7e44eb079d99ce1b9b2e2f8f3cf1b7f4211d7b85 (diff)
downloadllvm-33cbaab1416b234d5a08b41e3110d64a00b0651c.zip
llvm-33cbaab1416b234d5a08b41e3110d64a00b0651c.tar.gz
llvm-33cbaab1416b234d5a08b41e3110d64a00b0651c.tar.bz2
[funcattrs] Consistently treat calling a function pointer as a non-capturing read
We were being wildly inconsistent about what memory access was implied by an indirect function call. Depending on the call site attributes, you could get anything from a read, to unknown, to none at all. (The last was a miscompile.) We were also always traversing the uses of a readonly indirect call. This is entirely unneeded as the indirect call does not capture. The callee might capture itself internally, but that has no implications for this caller. (See the nice explanation in the CaptureTracking comments if that case is confusing.) Note that elsewhere in the same file, we were correctly computing the nocapture attribute for indirect calls. The changed case only resulted in conservatism when computing memory attributes if say the return value was written to. Differential Revision: https://reviews.llvm.org/D115916
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python')
0 files changed, 0 insertions, 0 deletions