diff options
author | Jessica Clarke <jrtc27@jrtc27.com> | 2024-05-22 23:56:43 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-05-22 23:56:43 +0100 |
commit | 7c937df05b7c636287e6058bb2e700618ff57c2f (patch) | |
tree | 687b4f09bfd2738a538ec1d6c12f9db8ede60ae0 /lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp | |
parent | cfa97699f76761f25c4c4b686a503466c427afce (diff) | |
download | llvm-7c937df05b7c636287e6058bb2e700618ff57c2f.zip llvm-7c937df05b7c636287e6058bb2e700618ff57c2f.tar.gz llvm-7c937df05b7c636287e6058bb2e700618ff57c2f.tar.bz2 |
[CodeGen] Forbid passing a PointerType to MVT::getVT and EVT::getEVT (#92671)
There is the expectation throughout CodeGen that, for types representing
"real" values, the MVT or EVT is self-contained. However, MVT::iPTR is
challenging, because it has no address space, and even if it did, there
often is no DataLayout immediately accessible to determine what actually
is the underlying type.
Historically it was documented as being TableGen-only, but that was lost
in 631bfdbee5b45eda9f99dff6a716d63c5698e4bd's conversion to using the
generated defines. Let's preserve that intent by not allowing it to
originate through accidental calls to get(E)VT with a PointerType. If
you need to support that, be sure to use something like TargetLowering's
getValueType, which takes a DataLayout and can map pointers to their
concrete MVTs. Whilst here, reintroduce documentation about these value
types being TableGen-only.
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp')
0 files changed, 0 insertions, 0 deletions