aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
diff options
context:
space:
mode:
authorJean Perier <jperier@nvidia.com>2023-01-06 09:57:08 +0100
committerJean Perier <jperier@nvidia.com>2023-01-06 09:57:15 +0100
commit241cb29187569274bbf327478e1665ff76528878 (patch)
tree93371219a35477dc6155db4714dc1f2899995abe /llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
parent543db09b97774ebf3c5da4a7044f1a94d6ba2975 (diff)
downloadllvm-241cb29187569274bbf327478e1665ff76528878.zip
llvm-241cb29187569274bbf327478e1665ff76528878.tar.gz
llvm-241cb29187569274bbf327478e1665ff76528878.tar.bz2
[flang] add hlfir.null to implement NULL()
In HLFIR, the address of a Fortran entity in lowering must be defined by an operation that has the FortranVariableOpInterface (it is a sanity requirement to ensure that the mlir::Value propagated in certain places of lowering can be reasoned about). fir.zero_bits does not have this interface and it makes little sense to add it since it can "zero initialize" more types than just addresses. Creating an hlfir.declare for null addresses is a bit too much (what would be the name), and it would be noisy in the IR. Instead add a small hlfir.null operation whose codegen is simply a replacement by fir.zero_bits. It may also later help dealing with the NULL(MOLD) cases in a nicer way (the current lowering of this uses special handling it). Differential Revision: https://reviews.llvm.org/D141040
Diffstat (limited to 'llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp')
0 files changed, 0 insertions, 0 deletions