Add support for representing array constants of any rank with MLIR
dense attribute. This greatly improves compile time and memory
usage of programs with large array constants. We still support only
arrays of a few basic types, such as integer, real and logic.
Fixes https://github.com/llvm/llvm-project/issues/60376
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D150686
Follow up of https://reviews.llvm.org/D149979 for lowering.
In Fortran, it is possible to assign a pointer to another pointer
with an undefined association status.
When using the runtime do to none trivial pointer association, if the
descriptor are garbage, the runtime cannot safely detect that it has
a garbage descriptor, and it cannot safely know the descriptor size
leading to undefined behavior.
Another reason to initialize descriptor of pointers is to record any
non deferred length parameter value.
Hence, although this is not required by Fortran, f18 always initialize
pointers to NULL().
This was already done in lowering for whole pointer object, but not for
pointer components.
This patch uses the related semantics patch that updated
derivedTypeSpe::HasDefaultInitialization to ensure pointer components
of local and global object are always initialized.
It adds tests to ensure that allocation of such derived type uses the
runtime to ensure the storage is initialized, and that structure
constructors are setting the descriptor component to NULL() if no
initial target is given.
Differential Revision: https://reviews.llvm.org/D150180
Instead of filling uninitialized global variables with "undef",
initialize them with 0. Only for Integer, Float or Logical type
variables. Complex, user defined data structures, arrays, etc
are not supported at this point.
This patch fixes the main problem of
https://github.com/llvm/llvm-project/issues/62432
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D149877
Assignment from a character dummy argument to a length-one character
variable resulted in illegal fir.convert:
%0 = fir.load %unboxed_dummy : !fir.ref<!fir.char<1,?>>
%1 = fir.convert %0 : (!fir.char<1,?>) -> !fir.char<1>
fir.store %1 to %local : !fir.ref<!fir.char<1>>
This change fixes the length-one assignment code to use proper casts.
For character dummy arguments with constant length we will now also
type cast the unboxed reference to the character type with constant length
during the lowering:
fir.convert %x : (!fir.ref<!fir.char<1,?>>) -> !fir.ref<!fir.char<1,8>>
I also adjusted the length-one assignment recognition so that in case
of same-length assignment we recognize length-one from either LHS or RHS
data types.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D149382
So far we've relied on AllocaOp to represent the dummy arguments
not declared for the current entry. With HLFIR we have to account
for hlfir::DeclareOp.
Differential Revision: https://reviews.llvm.org/D149231
Correctly create the temporary for argument absent in the entry statement.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D146447
Similary to non-optional argument, check if the argument is allocated before
doing the deallocation for intent(out) optional.
Depends on D145679
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D145682
Allocatable intent(out) are deallocated at the beginning of a function/subroutine.
For polyrmophic entities, the dynamic type need to be reseted to the declared
type. This patch makes sure this is done when the dummy argument is optional and
present.
Depends on D145674
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D145679
A block construct is an execution control construct that supports
declaration scopes contained within a parent subprogram scope or another
block scope. (blocks may be nested.) This is implemented by applying
basic scope processing to the block level.
Name uniquing/mangling is extended to support this. The term "block" is
heavily overloaded in Fortran standards. Prior name uniquing used tag `B`
for common block objects. Existing tag choices were modified to free up `B`
for block construct entities, and `C` for common blocks, and resolve
additional issues with other tags. The "old tag -> new tag" changes can
be summarized as:
-> B -- block construct -> new
B -> C -- common block
C -> YI -- intrinsic type descriptor; not currently generated
CT -> Y -- nonintrinsic type descriptor; not currently generated
G -> N -- namelist group
L -> -- block data; not needed -> deleted
Existing name uniquing components consist of a tag followed by a name
from user source code, such as a module, subprogram, or variable name.
Block constructs are different in that they may be anonymous. (Like other
constructs, a block may have a `block-construct-name` that can be used
in exit statements, but this name is optional.) So blocks are given a
numeric compiler-generated preorder index starting with `B1`, `B2`,
and so on, on a per-procedure basis.
Name uniquing is also modified to include component names for all
containing procedures rather than for just the immediate host. This
fixes an existing name clash bug with same-named entities in same-named
host subprograms contained in different-named containing subprograms,
and variations of the bug involving modules and submodules.
F18 clause 9.7.3.1 (Deallocation of allocatable variables) paragraph 1
has a requirement that an allocated, unsaved allocatable local variable
must be deallocated on procedure exit. The following paragraph 2 states:
When a BLOCK construct terminates, any unsaved allocated allocatable
local variable of the construct is deallocated.
Similarly, F18 clause 7.5.6.3 (When finalization occurs) paragraph 3
has a requirement that a nonpointer, nonallocatable object must be
finalized on procedure exit. The following paragraph 4 states:
A nonpointer nonallocatable local variable of a BLOCK construct
is finalized immediately before it would become undefined due to
termination of the BLOCK construct.
These deallocation and finalization requirements, along with stack
restoration requirements, require knowledge of block exits. In addition
to normal block termination at an end-block-stmt, a block may be
terminated by executing a branching statement that targets a statement
outside of the block. This includes
Single-target branch statements:
- goto
- exit
- cycle
- return
Bounded multiple-target branch statements:
- arithmetic goto
- IO statement with END, EOR, or ERR specifiers
Unbounded multiple-target branch statements:
- call with alternate return specs
- computed goto
- assigned goto
Lowering code is extended to determine if one of these branches exits
one or more relevant blocks or other constructs, and adds a mechanism to
insert any necessary deallocation, finalization, or stack restoration
code at the source of the branch. For a single-target branch it suffices
to generate the exit code just prior to taking the indicated branch.
Each target of a multiple-target branch must be analyzed individually.
Where necessary, the code must first branch to an intermediate basic
block that contains exit code, followed by a branch to the original target
statement.
This patch implements an `activeConstructStack` construct exit mechanism
that queries a new `activeConstruct` PFT bit to insert stack restoration
code at block exits. It ties in to existing code in ConvertVariable.cpp
routine `instantiateLocal` which has code for finalization, making block
exit finalization on par with subprogram exit finalization. Deallocation
is as yet unimplemented for subprograms or blocks. This may result in
memory leaks for affected objects at either the subprogram or block level.
Deallocation cases can be addressed uniformly for both scopes in a future
patch, presumably with code insertion in routine `instantiateLocal`.
The exit code mechanism is not limited to block construct exits. It is
also available for use with other constructs. In particular, it is used
to replace custom deallocation code for a select case construct character
selector expression where applicable. This functionality is also added
to select type and associate constructs. It is available for use with
other constructs, such as select rank and image control constructs,
if that turns out to be necessary.
Overlapping nonfunctional changes include eliminating "FIR" from some
routine names and eliminating obsolete spaces in comments.
Calling the runtime on disassociated pointer or unallocated
allocatable will trigger a segfault.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D144752
- Add a convertProcedureDesignatorToHLFIR that converts the
fir::ExtendedValue from the current lowering to a
fir.boxproc/tuple<fir.boxproc, len> mlir::Value.
- Allow fir.boxproc/tuple<fir.boxproc, len> as hlfir::Entity values
(a function is an address, but from a Fortran entity point of view,
procedure that are not procedure pointers cannot be assigned to, so
it makes a lot more sense to consider those as values).
- Modify symbol association to not generate an hlfir.declare for dummy
procedures. They are not needed and allowing hlfir.declare to declare
function values would make its verifier and handling overly complex
for little benefits (maybe an hlfir.declare_proc could be added if it
turnout out useful later for debug info and attributes storing
purposes).
- Allow translation from hlfir::Entity to fir::ExtendedValue.
convertToBox return type had to be relaxed because some intrinsics
handles both object and procedure arguments and need to lower their
object arguments "asBox". fir::BoxValue is not intended to carry
dummy procedures (all its member functions would make little sense
and its verifier does not accept such type).
Note that AsAddr, AsValue and AsBox will always return the same MLIR
value for procedure designators because they are always handled the
same way in FIR.
Differential Revision: https://reviews.llvm.org/D143585
HLFIR requires mapping symbol to a single mlir::Value (produced
by a fir::FortranVariableOpInterface), while the current lowering
maps the value to a fir::ExtdendedValue.
So far, the HLFIR symbol query was a special one. Hence, all the code
directly using symMap.lookupSymbol and symMap.addSymbol did not work
with the lowering to HLFIR.
Refactor the code so that symbol lookup and add symbol go through
the converter in a centralize place that handles the HLFIR case
(translate fir::FortranVariableOpInterface to fir::ExtdendedValue
in lookups, and generate hlfir.declare when adding symbols).
In the refactoring, fir::FortranVariableOpInterface is added as
a symbolBox variant to avoid special casing all lookups (shallowLookup...).
Remove some unused SymbolBox member function instead of updating
them.
Differential Revision: https://reviews.llvm.org/D143395
This will allow IntrinsicCall to be used in passes to implement hlfir
transformational intrinsic operations.
Differential Revision: https://reviews.llvm.org/D143084
Makes use of fir.type_desc in order to delay the type desc address
resolution. The lowering inserts fir.type_desc operation instead of fir.addr_of
operation pointing to the fir.global type descriptor. The fir.type_desc
operation is then lowered in code gen to an address of operation in the LLVM
dialect. At this stage, the type descriptor is generated in all cases.
Reviewed By: vdonaldson
Differential Revision: https://reviews.llvm.org/D142920
This patch implements the derived-type finalization for
monomorphic and polymorphic derived-type.
The finalization is done through a call to the `Destroy`
runtime function so the allocatable component object are also
finalized correctly when needed. It would be possible to finalize
monomorphic derived-type with non finalizable component with a
direct call to their finalize subroutine.
7.5.6.3 point 1: LHS nonallocatable object and LHS allocatable
object finalization. Done with call to `Destroy` for monomorphic
derived-type and through `Assign` for polymorphic entities.
7.5.6.3 point 2: Done within the deallocation calls.
7.5.6.3 point 3: A function context is added to the bridge to
attach finalization that need to happen on function/subroutine
exit.
7.5.6.3 point 4: BLOCK construct not yet implemented.
7.5.6.3 point 5/6: Finalization attach to the stmtCtx in a
similar way than 9.7.3.2 point 4.
7.5.6.3 point 7: INTENT(OUT) finalization done with a
call to `Destroy` runtime function call.
This patch passes 9/10 tests in the proposed test-suite
https://github.com/llvm/llvm-test-suite/pull/13
- The case with BLOCK construct will be implemented later when
BLOCK are implemented upstream.
- Automatic deallocation is not yet implemented. Finalization triggered
by automatic deallocation is then not triggered.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D142707
Compare to other component ref lowering, the hlfir.designate result type
computation is different, and the allocatable/pointer/contiguous must
be set on the hlfir.designate so that the component attributes are
kept in the IR.
Differential Revision: https://reviews.llvm.org/D142111
Adds support for:
- referencing a whole allocatable/pointer symbol
- passing allocatable/pointer in a call
This required update in HLFIRTools.cpp helpers so that the
raw address, extents, lower bounds, and type parameters of a
fir.box/fir.class can be extracted.
This is required because in hlfir lowering, dereferencing a
pointer/alloc is only doing the fir.load fir.box part, and the
helpers have to be able to reason about that fir.box without the
help of a "fir::FortranVariableOpInterface".
Missing:
- referencing part of allocatable/pointer (will need to update
Designator lowering to dereference the pointer/alloc). Same
for whole allocatable and pointer components.
- allocate/deallocate/pointer assignment statements.
- Whole allocatable assignment.
- Lower inquires.
Differential Revision: https://reviews.llvm.org/D142043
As mentioned in section 7.3.2.3 note 7, The dynamic type of an unallocated
allocatable object or a disassociated pointer is the same as its declared type.
This patch adds two function to the runtime:
- `PointerDeallocatePolymorphic`
- `AllocatableDeallocatePolymorphic`
These two functions take a DerivedTypeDesc pointer of the declared type.
The lowering is updated accordingly to call these functions for polymorphic
and unlimited polyrmophic entities. For unlimited polymorphic entities, the
dynamic type is set to nullptr when the entity is on an unallocated or
disassociated state.
Reviewed By: PeteSteinfeld, klausler
Differential Revision: https://reviews.llvm.org/D141519
Deallocation of intent(out) allocatable was done in D133348. This patch adds
an if guard when the deallocation is done through a runtime call. The runtime
is crashing if the box is not allocated. Call the runtime only if the box is
allocated. This is the case for derived type, polymorphic and unlimited
polymorphic entities.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141427
Move the code to lower an expression to address or a box in HLFIR from
Bridge.cpp to ConvertExpr.cpp so that it can be used inside
ConvertVariable.cpp (that needs to use a different symbol map that the
one held in the bridge).
Lower NULL to hlfir.null.
This allows lowering derived type constant structure constructors with
pointer components into fir.global.
Differential Revision: https://reviews.llvm.org/D141276
The current lowering of initial target in fir.global is relying
on how fir.box are created: instead of using a fir.rebox to add
the POINTER attribute to the created descriptor, it is looking
for a fir.embox defining operation and creating a copy of
it with a different result types.
The rational for doing so was that fir.rebox codegen was not possible
inside fir.global because it expects to manipulate the input fir.box
in memory, while objects cannot be manipulated in memory inside
a fir.global region that must be constant foldable.
But this approach has two problems:
- it won't work with hlfir where fir.box may be created by more
operations than fir.embox (e.g. hlfir.delcare or hlfir.designate).
In general, looking for a precise defining op for a value is
fragile.
- manually copying and modifying an operation is risky: it is easy
to forget copying some default operands (that could be added later).
This patch modifies the helpers to get descriptor fields so that they
can both operate on fir.box lowered in memory or in an llvm.struct
value. This enables the usage of fir.rebox in fir.global op.
The fallout in FIR tests is caused by the usage of constant index
when creating GEP (because extractOp requires constant indices).
MLIR builder uses i32 bit constant indices when non mlir::Value
indices are passed to the MLIR GEP op builder. Previously,
an 64 nist mlir constant value was created and passed to the GEP
builder. In this case, the builder respect the value type when
later generating the GEP.
Given this changes impact the "dimension" index that can, per
Fortran requirement, not be greated than 15, using a 32 bit index
is just fine and actually simplify the MLIR LLVM IR generation.
The fallout in lowering tests is caused by the introduction
of the fir.rebox everytime an initial target is created.
Differential Revision: https://reviews.llvm.org/D141136
This patch adds runtime default initialization for polymorphic
dummy argument. The dynamic type might require default initialization
but not the declared type.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141278
A previous patch (https://reviews.llvm.org/D136955) already refactored
intrinsic constant lowering to place in its own file and allow using it from
both the current lowering and the new lowering to HLFIR.
This patch does the same for derived types. The core function
"genStructComponentInInitializer" is moved from ConvertExpr.cpp and
renamed "genInlinedStructureCtorLitImpl" into ConvertConstant.cpp
without significant logic change.
Then, genScalarLit, genArrayLit (and genInlinedArrayLit/genOutlinedArrayLit)
are updated to support derived types.
The core aspect of derived type constant lowering that differs between
the current lowering and the HLFIR update is the way
addresses/initial target descriptors are built when part of a derived
type constant. This part happens in ConvertVariable.cpp (since the
address of a variable is taken in an initializer and is left TODO).
The mangling of derived type global literal constant is fixed: it did not embed
the derived type name and could cause "conflicts" between unrelated
derived types containing the same data. However, the hash remains
unstable between two compilation of the same file. This is not a
correctness issue and would require a lot of work to hash the derived
type constant data without hashing some irrelevant (but not out of bound)
data in the compile time data structure that holds derived type
constants (Constant<SomeDerived>). This may have to be revisited later.
Differential Revision: https://reviews.llvm.org/D140986
Enable lowering of statement function references in HLFIR. This follows
the same principle as statement function lowering with the current
lowering:
- Actual arguments are lowered and mapped to the statement function
dummy symbols.
- "HostAssociated" symbols are mapped to their host values (these are
the symbols referred to inside the statement function expressions that
are not statement function dummies. e.g: `x` in `stmt_func(i) =
x(i)`).
- The statement function expression is evaluated.
evaluate::SetLength has to be lowered to deal with statement functions
returning characters since the front-end is generating one to ensure the
statement function expression value is trimmed/padded to match the statement
function declared type.
Differential Revision: https://reviews.llvm.org/D140220
A submodule is a program unit that may contain the implementions of procedures
declared in an ancestor module or submodule.
Processing for the equivalence groups and variables declared in a submodule
scope is similar to existing processing for the equivalence groups and
variables in module and procedure scopes. However, module and procedure scopes
are tied directly to code in the Pre-FIR Tree (PFT), whereas processing for a
submodule must have access to an ancestor module scope that is guaranteed
to be present in a .mod file, but is not guaranteed to be in the PFT. This
difference is accommodated by tying processing directly to a front end scope.
Function scopes that can be processed on the fly are done that way; the
resulting variable information is never stored. Module and submodule scopes
whose symbol information may be needed during lowering of any number of module
procedures are instead cached on first use, and reused as needed.
These changes are a direct extension of current code. All module and submodule
variables in scope are processed, whether referenced or not. A possible
alternative would be to instead process symbols only when first used. While
this could ultimately be beneficial, such an approach must account for the
presence of equivalence groups. That information is not currently available
for on-the-fly variable processing.
Some additional changes are needed to include submodules in places where
modules must be considered, and to include separate module procedures in
places where other subprogram variants are considered. There is also a fix
for a bug involving the use of variables in an equivalence group in a
namelist group, which also involves scope processing code.
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
Update lowering to generate hlfir.declare instead of fir.declare.
Introduce the hlfir::Entity class that will be used to work with
Fortran objects in HLFIR transformation.
Fix lower bounds that where swapped with extents in fir.declare
generation.
Update tests that expected fir.declare.
Differential Revision: https://reviews.llvm.org/D137951
This patch moves intrinsic evaluate::Constant<T> lowering into its own
unit outside of ScalarExpr and genarr lowering so that it can
be used by the new lowering without any changes.
DerivedType lowering cannot be shared at that stage because it is too
correlated with the current lowering (requires structure constructor
and designator lowering).
The code had to be refactored quite a bit so that it could be carved
out, but the only "functional" change is that the length of character
arrays lowered by genarr is now `index` instead of `i64` (see test change).
One non-functional benefit of the change is that `toEvExpr` is not
needed anymore and some compile time copies of big constant arrays
that it was causing are removed (see old calls in previous genarr code),
although I am not sure any compile time speed-ups are visible here.
Differential Revision: https://reviews.llvm.org/D136955
This patch adds the kernel to lower evaluate::Expr to HLFIR to a
hlfir::FortranEntity (a single mlir::Value that can be interpreted as
a Fortran variable or the value of a Fortram expression).
It implements lowering of simple name designators ("x") and starts
adding a translation layer in AbstractConverter::genExprBox and
AbstractConverter::genExprAddr so that the new expression lowering
can be used without any changes for now in the current statement and
construct lowering.
Differential Revision: https://reviews.llvm.org/D136453
Lower scalar and explicit shape arrays to fir.declare under the -hlfir option.
Update the SymMap so that it can hold fir::FortranVariableInterface.
The plan is to go towards a SymMap that only contains fir::FortranVariableInterface
once current expression lowering can be replaced. This should make the SymMap lighter
than it is today (SymBox/ExtendedValue are above 256 bytes).
Assumed shape, allocatable and pointer are left TODOs for now. Anything with a
specification expression that is not a constant expression will only be able to
be lowered when the HLFIR expression lowering skeleton is added.
Differential Revision: https://reviews.llvm.org/D136252
mapSymbolAttributes currently has a lot of very similar code for
each kind of explicit shape and scalar symbols.
Refactor it so that the change to lower symbols with fir.declare
can be added in centralized places instead of being scattered.
This is a preparation patch and fir.declare is not yet added.
Differential Revision: https://reviews.llvm.org/D136061
It seems the needed functionality was already implemented for host associations,
so turn that code into a function and move it into a (hopefully appropriate)
common location and reuse it.
Differential Revision: https://reviews.llvm.org/D135481
When calling a type-bound procedure from a polymoprhic array element,
the dynamic type needs to be extracted from the array descriptor
and passed to the embox operation for the pass-object.
Depends on D135809
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D135856
TARGET dummy arguments have fir.target attribute attached to them,
but globals do not have any sign of TARGET. This patch adds
target attribute for globals, which can be queried via
::fir::GlobalOp::getTarget().
Differential Revision: https://reviews.llvm.org/D135313
This patch updates lowering to produce the correct fir.class types for
various polymorphic and unlimited polymoprhic entities cases. This is only the
lowering. Some TODOs have been added to the CodeGen part to avoid errors since
this part still need to be updated as well.
The fir.class<*> representation for unlimited polymorphic entities mentioned in
the document has been updated to fir.class<none> to avoid useless work in pretty
parse/printer.
This patch is part of the implementation of the poltymorphic
entities.
https://github.com/llvm/llvm-project/blob/main/flang/docs/PolymorphicEntities.md
Depends on D134957
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D134959
NULL intrinsic with a MOLD argument can be used in a type constructor.
This patch handles this use case with a specific lowering that create
an unallocated box with the MOLD type.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D134554
BIND(C) Function returning character must return it by value and
not as hidden argument like done currently. This patch update the
code to return it by value for both use cases.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D134530
In some case, the ENTRY statement in a procedure is including some
dummy argument. Until now, deallocation of intent(out) allocatable was
not checking for this and it could result in a segmentation fault.
This patch avoids deallocation when the value is not in the ENTRY stmt.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D134342
From Fortran 2018 standard 9.7.3.2 point 6:
When a procedure is invoked, any allocated allocatable object that is an actual
argument corresponding to an INTENT (OUT) allocatable dummy argument is
deallocated; any allocated allocatable object that is a subobject of an actual
argument corresponding to an INTENT (OUT) dummy argument is deallocated.
Deallocation is done on the callee side. For BIND(C) procedure, the deallocation
is also done on the caller side.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D133348
Non-global variable which can be in threadprivate directive must be one
variable in main program, and it has implicit SAVE attribute. Take it as
with SAVE attribute, so to create GlobalOp for it to simplify the
translation to LLVM IR.
Reviewed By: NimishMishra
Differential Revision: https://reviews.llvm.org/D127047
This patch is part of the upstreaming effort from fir-dev branch.
This is the last patch for the upstreaming effort.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D129187
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Even though the array is declared with '*' upper bounds, it has an
initial value that has a statically known shape. Use the shape from
the type of the initializer when the declared size is '*'.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D128889
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
