aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h
diff options
context:
space:
mode:
authorNicolas Vasilache <nicolas.vasilache@gmail.com>2021-07-21 22:01:51 +0000
committerMehdi Amini <joker.eph@gmail.com>2021-07-21 22:06:50 +0000
commita664c14001fa2359604527084c91d0864aa131a4 (patch)
tree7f650feb2503ce96dfccee283ce6615ff38b4b5c /lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h
parentc75a2bbe080c8ff2a62286e816dfde914f1ae1f6 (diff)
downloadllvm-a664c14001fa2359604527084c91d0864aa131a4.zip
llvm-a664c14001fa2359604527084c91d0864aa131a4.tar.gz
llvm-a664c14001fa2359604527084c91d0864aa131a4.tar.bz2
[mlir][LLVM] Revert bareptr calling convention handling as an argument materialization.
Type conversion and argument materialization are context-free: there is no available information on which op / branch is currently being converted. As a consequence, bare ptr convention cannot be handled as an argument materialization: it would apply irrespectively of the parent op. This doesn't typecheck in the case of non-funcOp and we would see cases where a memref descriptor would be inserted in place of the pointer in another memref descriptor. For now the proper behavior is to revert to a specific BarePtrFunc implementation and drop the blanket argument materialization logic. This reverts the relevant piece of the conversion to LLVM to what it was before https://reviews.llvm.org/D105880 and adds a relevant test and documentation to avoid the mistake by whomever attempts this again in the future. Reviewed By: arpith-jacob Differential Revision: https://reviews.llvm.org/D106495
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptedProcessPythonInterface.h')
0 files changed, 0 insertions, 0 deletions