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
The defining op of HLFIR variables is expected to be visible
in most cases, but HLFIR codegen won't rely on it from a correctness
point of view.
This patch allows building a fir.shape from an hlfir::Entity does not
have a visible FortranVariabeInterface defining op.
Differential Revision: https://reviews.llvm.org/D140099
Without any optimization or when it cannot be optimized before
bufferization, an hlfir.elemental lowers to an array temporary.
Its codegen consists in:
- allocating a temp given the type, shape, and length parameter arguments.
- generating a loop nest given the elemental shape
- inlining the body of the elemental inside the loops, and replacing the
yield_element by an assignment to an element of the temp.
Differential Revision: https://reviews.llvm.org/D140093
Same as fir.no_reassoc but accepts hlfir.expr type. It is needed because
FIR operation can only produce FIR types, and I do not want to change
that for now.
Depends on D139519
Differential Revision: https://reviews.llvm.org/D139520
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
Add the default unoptimized implementation implementation
of hlfir.assign. It relies on the runtime for array assignment
and always makes a temp of the right hand side for arrays.
Assignment optimization will be done when all HLFIR pieces are in place
and aliasing analysis is available.
Differential Revision: https://reviews.llvm.org/D139426
Add hlfir.associate and hlfir.end_associate codegen.
To properly allow reusing the bufferized expression storage for the
newly created variable, bufferization of hlfir.expr has to be updated
so that hlfir.expr are translated to a variable and a boolean to
indicate if the variable storage needs to be freed after the expression
was used. That way the responsibility to free the bufferized expression
can be passed to the variable user, and applied in the
hlfir.end_associate.
Right now, not of the bufferized expression are heap allocated, so
generating the conditional freemem in hlfir.end_associate is left as
a TODO for when it can be tested.
Differential Revision: https://reviews.llvm.org/D139020
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
hlfir.concat codegen happens in the "bufferization" pass: the pass
that place hlfir.expr in memory and transform all operations producing
or accepting hlfir.expr arguments into operations operating on memory.
Since this pass gets rid of the hlfir.expr type, this is a full
translation pass.
So far hlfir.concat codegen re-uses the current concatenation lowering helper
and only supports concatenation of two strings at a time. This matches
what lowering to HLFIR without any optimization produces. More optimized
versions will be developed later.
Differential Revision: https://reviews.llvm.org/D138673
hlfir.declare codegen generates a fir.declare, and may generate a
fir.embox/fir.rebox/fir.emboxchar if the base value does not convey
all the variable bounds and length parameter information.
Leave OPTIONAL as a TODO to keep this patch simple. It will require
making the embox/rebox optional to preserve the optionality aspects.
Differential Revision: https://reviews.llvm.org/D137789
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
This patch adds the basic dialect definition of the HLFIR dialect that
was described in https://reviews.llvm.org/D134285.
It adds the definition of the hlfir.expr type and related tests so that
it can be verified that the dialect is properly hooked up by the tools.
Operations will be added as progress is made in the expression
lowering update.
Differential Revision: https://reviews.llvm.org/D136328
