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
This will implement evaluate::SetLength where the length of
a character entity is changed (with trimming and padding).
Differential Revision: https://reviews.llvm.org/D140219
This is part of an effort to migrate from llvm::Optional to
std::optional. This patch changes the way mlir-tblgen generates .inc
files, and modifies tests and documentation appropriately. It is a "no
compromises" patch, and doesn't leave the user with an unpleasant mix of
llvm::Optional and std::optional.
A non-trivial change has been made to ControlFlowInterfaces to split one
constructor into two, relating to a build failure on Windows.
See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>
Differential Revision: https://reviews.llvm.org/D138934
Lower binary and unary elemental operations with an array argument
using hlfir.elemental, hlfir.yield_element, and hlfir.apply.
Concat implementation, which is a binary operation, is moved to a
BinaryOp struct so that it can leverage this new code.
This patch implements the "not yet implemented: character array
expression temp with dynamic length" TODO of the current lowering
by splitting the result length computation from the result value
computation. That way, the result length computation can be done
before lowering the operation to an hlfir.elemental, and the length
of the hlfir.elemental is known and storage for it can later be
allocated.
It adds a DesignatorOp builder to make "dumb" indexing (without triplets,
component, substrings or derived type component ref) easier since indexing
needs to be generated for array variables in elemental expression (in
the added hlfir::genElementAt helper).
Differential Revision: https://reviews.llvm.org/D140040
hlfir.as_expr allows taking a value from a character, derived type,
or array expressions. This will allow implementing parentheses.
Combining as_expr + hlfir.associate will allow creating a variable copy
into a new temporary variable.
A later patch will add the ability to "move" a variable into an
expression (to give ownership of the variable storage to the expression,
with the commitment that the variable will not be used anymore).
Differential Revision: https://reviews.llvm.org/D139519
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
These operations allow creating an HLFIR variable from a HLFIR value and
destroying it at the end of the variable lifetime.
This will both be used to implement procedure reference arguments association
when the actual is an expression, and to implement the Fortran associate
construct when the associated entity is an expression.
See https://github.com/llvm/llvm-project/blob/main/flang/docs/HighLevelFIR.md
for more details.
Differential Revision: https://reviews.llvm.org/D138996
This operation will be used to declare named variables in HLFIR.
See the added description in HLFIROpBase.td for more info about it.
The motivation behind this operation is described in https://reviews.llvm.org/D137634.
The FortranVariableInterface verifier is changed a bit. It used to
operate using the result type to verify the provided shape and length
parameters. This is a bit incorrect because what matters to verify the
information is the input address (This worked OK with fir.declare where
the input memref type is the same as the output result). Also, not all
operation defining variables will have an input memref with the same
meaning (hlfir.designate and hlfir.associate for instance).
Hence, this verifier is now optional and must be provided a memref to
operate.
Differential Revision: https://reviews.llvm.org/D137781
