diff options
| author | Heejin Ahn <aheejin@gmail.com> | 2025-01-15 11:53:51 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-01-15 11:53:51 -0800 |
| commit | 5a90168fa34e15b544d7749ca4d247a16d360119 (patch) | |
| tree | bdcc011b3a1c7bb985c8fa58e498f38f2df1d1bd /lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h | |
| parent | 6655c53ff02f0ffca0fcaa3261e14c2a6417d3da (diff) | |
| download | llvm-5a90168fa34e15b544d7749ca4d247a16d360119.zip llvm-5a90168fa34e15b544d7749ca4d247a16d360119.tar.gz llvm-5a90168fa34e15b544d7749ca4d247a16d360119.tar.bz2 | |
[ValueTracking] Provide getUnderlyingObjectAggressive fallback (#123019)
This callsite assumes `getUnderlyingObjectAggressive` returns a non-null
pointer:
https://github.com/llvm/llvm-project/blob/273a94b3d5a78cd9122c7b3bbb5d5a87147735d2/llvm/lib/Transforms/IPO/FunctionAttrs.cpp#L124
But it can return null when there are cycles in the value chain so there
is no more `Worklist` item anymore to explore, in which case it just
returns `Object` at the end of the function without ever setting it:
https://github.com/llvm/llvm-project/blob/9b5857a68381652dbea2a0c9efa734b6c4cf38c9/llvm/lib/Analysis/ValueTracking.cpp#L6866-L6867
https://github.com/llvm/llvm-project/blob/9b5857a68381652dbea2a0c9efa734b6c4cf38c9/llvm/lib/Analysis/ValueTracking.cpp#L6889
`getUnderlyingObject` does not seem to return null either judging by
looking at its code and its callsites, so I think it is not likely to be
the author's intention that `getUnderlyingObjectAggressive` returns
null.
So this checks whether `Object` is null at the end, and if so, falls
back to the original first value.
---
The test case here was reduced by bugpoint and further reduced manually,
but I find it hard to reduce it further.
To trigger this bug, the memory operation should not be reachable from
the entry BB, because the `phi`s should form a cycle without introducing
another value from the entry. I tried a minimal `phi` cycle with three
BBs (entry BB + two BBs in a cycle), but it was skipped here:
https://github.com/llvm/llvm-project/blob/273a94b3d5a78cd9122c7b3bbb5d5a87147735d2/llvm/lib/Transforms/IPO/FunctionAttrs.cpp#L121-L122
To get the result that's not `ModRefInfo::NoModRef`, the length of `phi`
chain needed to be greater than the `MaxLookup` value set in this
function:
https://github.com/llvm/llvm-project/blob/02403f4e450b86d93197dd34045ff40a34b21494/llvm/lib/Analysis/BasicAliasAnalysis.cpp#L744
But just lengthening the `phi` chain to 8 didn't trigger the same error
in `getUnderlyingObjectAggressive` because `getUnderlyingObject` here
passes through a single-chain `phi`s so not all `phi`s end up in
`Visited`:
https://github.com/llvm/llvm-project/blob/9b5857a68381652dbea2a0c9efa734b6c4cf38c9/llvm/lib/Analysis/ValueTracking.cpp#L6863
So I just submit here the smallest test case I managed to create.
---
Fixes #117308 and fixes #122166.
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h')
0 files changed, 0 insertions, 0 deletions
