diff options
author | agozillon <Andrew.Gozillon@amd.com> | 2025-01-30 17:31:50 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-01-30 17:31:50 +0100 |
commit | 4186805060bb06dc3362707d45e6f0f826208a8f (patch) | |
tree | 764994dc12048d42c0f966f1d9f55265a8daccc4 /lldb/source/Interpreter/CommandInterpreter.cpp | |
parent | 5b65896ad66e1c63d3d5b708f0b748a860272b21 (diff) | |
download | llvm-4186805060bb06dc3362707d45e6f0f826208a8f.zip llvm-4186805060bb06dc3362707d45e6f0f826208a8f.tar.gz llvm-4186805060bb06dc3362707d45e6f0f826208a8f.tar.bz2 |
[Flang][MLIR] Extend DataLayout utilities to have basic GPU Module support (#123149)
As there is now certain areas where we now have the possibility of
having either a ModuleOp or GPUModuleOp and both of these modules can
have DataLayout's and we may require utilising the DataLayout utilities
in these areas I've taken the liberty of trying to extend them for use
with both.
Those with more knowledge of how they wish the GPUModuleOp's to interact
with their parent ModuleOp's DataLayout may have further alterations
they wish to make in the future, but for the moment, it'll simply
utilise the basic data layout construction which I believe combines
parent and child datalayouts from the ModuleOp and GPUModuleOp. If there
is no GPUModuleOp DataLayout it should default to the parent ModuleOp.
It's worth noting there is some weirdness if you have two module
operations defining builtin dialect DataLayout Entries, it appears the
combinatorial functionality for DataLayouts doesn't support the merging
of these.
This behaviour is useful for areas like:
https://github.com/llvm/llvm-project/pull/119585/files#diff-19fc4bcb38829d085e25d601d344bbd85bf7ef749ca359e348f4a7c750eae89dR1412
where we have a crossroads between the two different module operations.
Diffstat (limited to 'lldb/source/Interpreter/CommandInterpreter.cpp')
0 files changed, 0 insertions, 0 deletions