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
When an array element is extracted from an unlimited polymorphic array, the
emboxing of this element has to retrive the type code and element size from
the initial array. This patch retrive this information through the extracted
type descriptor.
This situation can be found in code like:
```
subroutine sub1(a)
class(*) :: a(:)
select type (x=>a(1))
type is (integer)
x = 10
end select
end subroutine
```
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141274
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
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
Address several issues involving control flow graph generation and
structured code ops.
- Fix a problem with constructs nested inside unstructured selection
constructs. This is a general problem involving branches that are
implied rather than explicit. It is addressed in the generic genFIR
"wrapper" function that calls individual statement-specific genFIR calls.
- The previous fix requires some compensating changes in IF and DO
construct code lowering.
- Streamline the code to generate explicit DO loop variable updates.
- Fix a problem with the individual detailed genFIR calls made in the
genFIR(SelectTypeConstruct) call.
- Modify control flow graph generation to support the insertion of
deallocation and finalization code when lowering most END <construct>
statements.
Adding support for ppc64 (big endian) in order to support flang on 64 bit AIX
Reviewed By: clementval, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D138390
The loops generated under IsContiguous check for copy-in/copy-out
result in LLVM backend spending too much time optimizing them.
At the same time, the copy loops do not provide any optimization
opportunities with the surrounding code (since they are executed
under runtime IsContiguous check), so the copy code may be optimized
on its own and this can be done in runtime.
I thought I could implement and use new APIs for packing/unpacking
non-contiguous data (interfaces added in D136378), but then I found
that Assign() is already doing what is needed. If performance
becomes an issue for these loops, we can optimize code in Assign()
rather than creating new APIs.
Thus, this change makes use of Assign() for copy-in/copy-out
of boxed objects, and this is done only if the objects
are non-contiguous during execution. Copies for non-boxed
objects (e.g. for passing as VALUE dummy argument) are still
done inline, because they can potentially be optimized with
surrounding loops.
I added internal -inline-copyinout-for-boxes option to revert to the old
behavior just to make it easier to triage performance regressions,
if any appear after the change.
CPU2017/521.wrf compiles for 2179 seconds without the change and
the module_dm.f90 compiled with -O0 (without -O0 this single
module compiles for 5775 seconds). With the change total compilation
time of the benchmark reduces to 722 seconds.
Differential Revision: https://reviews.llvm.org/D140446
Addresses and properties (bounds, length parameters) of host
variables associated in an internal procedure were all passed via
an extra tuple argument of the internal procedure.
This extra tuple is in general an overhead: it must be created and
passed, and require creating thunks when taking the address of the
internal procedure.
This patch allows not using the tuple for host global variables
(from modules, common block, or local saved variables) since they can
be instantiated from the fir.global symbol in the internal procedure
instead.
Add a fir.internal_proc attribute to mlir::FuncOp for internal procedures
so that ArrayValueCopy can still detect internal procedures even if they
do not have a tuple argument.
Differential Revision: https://reviews.llvm.org/D140288
Hlfir.designate was made to support substrings but so far substrings
were not yet lowered to it. Implement support for them.
Differential Revision: https://reviews.llvm.org/D140310
The runtime implementation uses the recurrence relations
`J(n-1, x) = (2.0 / x) * n * J(n, x) - J(n+1, x)`
`Y(n+1, x) = (2.0 / x) * n * Y(n, x) - Y(n-1, x)`
(see https://dlmf.nist.gov/10.74.iv and https://dlmf.nist.gov/10.6.E1).
Although the standard requires that `N1` and `N2` in `BESSEL_JN(N1, N2, x)`
and `BESSEL_YN(N1, N2, x)` be non-negative, this is not checked in the
runtime functions. This is in keeping with some other compilers which also
return some results when `N1` and/or `N2` are negative.
The special case for `x == 0` is handled in different runtime functions
for each of `BESSEL_JN` and `BESSEL_YN`. The lowering code checks for this
case and inserts the checks and the appropriate runtime calls in FIR.
The existing tests for the two intrinsics was modified to keep the style
consistent with the additional lowering tests that were added.
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
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
When some arguments that specify bit positions, shift counts, and field sizes are
constant at compilation time, but other arguments are not constant, the compiler
should still validate the constant ones. In the current sources, validation is
only performed for intrinsic references that can be folded to constants.
Differential Revision: https://reviews.llvm.org/D140152
When specific procedures of a generic have dummy procedures,
underspecified actual procedures can match more than one specific
procedure. This can happen with actual procedures that are
externals with implicit interfaces, including the completely
unspecified case of a PROCEDURE() or EXTERNAL that doesn't even
differentiate between a subroutine and a function.
Generic resolution can already handle cases of ambiguous resolution
due to the use of NULL() actual arguments with no MOLD= arguments
to define their types. Extend the handling of ambiguous actual
arguments to include the case of underspecified actual procedures.
Differential Revision: https://reviews.llvm.org/D140151
The pointers and allocatables that appear in ALLOCATE and DEALLOCATE
statements need to be subject to the general definability checks so
that problems with e.g. PROTECTED objects can be caught.
(Also: regularize the capitalization of the DEALLOCATE error messages
while I'm in here so that they're consistent with the messages that
can come out for ALLOCATE.)
Differential Revision: https://reviews.llvm.org/D140149
Constraint C1529 requires that the base object of a type-bound procedure
reference be a scalar if the TBP has the NOPASS attribute. Most
compilers do not enforce this constraint and it does not appear to
have any implementation justification, so emit portability warning.
On the other hand, we fail to enforce C919 for references to
procedure pointer components, whose base objects must of course
be scalars in order to avoid ambiguity and empty arrays, whether
NOPASS is present or not.
Differential Revision: https://reviews.llvm.org/D140148
Nice try, but no, you can't initialize an instance of a derived type using a
structure constructor that has a component corresponding to an allocatable
component.
Differential Revision: https://reviews.llvm.org/D140144
When generating the `fir.dispatch_table` operation, the name of the parent
derived-type needs to be mangled. For this the type instantiation
DerivedTypeSpec needs to be retrieved to have the correct kind type parameters.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D140209
An unlimited polymoprhic entity can be allocated with a derived type
spec or an intrinsic type spec. This patch add the generation of the
runtime function call when the allocation is done with an intrinsic
type spec.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D140207
The ProcInterface structure is used only by ProcEntityDetails; it represents
what a program might have put in parentheses in a procedure-declaration-stmt,
either the name of a procedure interface or a declaration-type-spec.
If a procedure entity has an implicit interface, the function result
type (if any) can be kept in EntityDetails::type_, which already exists
and is currently redundant for ProcEntityDetails symbols.
All that is really needed is a nullable Symbol pointer in ProcEntityDetails
to point to the procedure's explicit interface, when it has one.
Also, catch the case where a procedure has an explicit interface
and a program attempts to also give it a type.
Differential Revision: https://reviews.llvm.org/D140134
When a defined object is an array with a vector subscript, and it has a
finalizable type, it may have a final subroutine with a matching or
assumed rank dummy argument that cannot be called. Unless there is
also a suitable elemental final subroutine, diagnose such a case
with an error message.
Differential Revision: https://reviews.llvm.org/D140131
Most attributes apply to only object or only procedure entities,
and attempts to apply them to other kinds of symbol table entries
are caught in name resolution when ConvertToObjectEntity() or
ConvertToProcEntity() fails. However, the POINTER attribute can
be applied to both, and name resolution can't perform that conversion
yet, and as a result we don't catch many kinds of silly errors.
Fix by ensuring that the symbol is of a type that could eventually
become an object or procedure entity if it is not one already.
Differential Revision: https://reviews.llvm.org/D140137
Lower procedure ref to user defined elemental procedure when:
- there are no arguments that may be dynamically optional
- for functions, the result has no length parameters
- the reference can be unordered
- there are not character by value arguments
This uses the recently added hlfir.elemental operation and tools.
The "core" of the argument preparation is shared between elemental
and non elemental calls (genUserCalls is code moved without any
functional changes)
Differential Revision: https://reviews.llvm.org/D140118
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
When a function has an implicit interface its result type may
not have a deferred type parameter.
Differential Revision: https://reviews.llvm.org/D140132
Semantic checking for DEALLOCATE statements omitted checks for
polymorphic objects and ultimate allocatable components in a pure
procedure, which if not caught would allow execution of an impure
FINAL subroutine defined on a type extension.
Differential Revision: https://reviews.llvm.org/D140129
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
In SELECT TYPE, within the block following TYPE IS, the associating entity is not polymorphic.
It has the type named in the type guard and other properties taken from the
selector. Within the block following a CLASS IS type guard statement, the
associating entity is polymorphic and has the declared type named in the type
guard statement.
This patch makes sure the associating entity matches the selector if it is
an array, a pointer or an allocatable.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D140017
Exponentiation is lowered to either math::FPowI or Fortran runtime
call (in case of --math-runtime=precise).
MathToFuncs convertor will convert math::FPowI operations with
exponent width >32 to calls of outlined implementations and otherwise
will leave the operation to MathToLLVM convertor.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139806
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 implements @klausler's suggestion in `llvm-project` [issue #58973](https://github.com/llvm/llvm-project/issues/58973); encountering the `VOLATILE` attribute should produce a __warning__, not a __fatal error__.
When tested on the following Fortran program `snem0601_012_.f90`:
```fortran
module mod
contains
subroutine sub(m6,error)
integer,intent(inout) :: error
integer,volatile :: m6
if (any ((/m6/).ne.(/6/))) &
& then
error = 1
end if
end subroutine
end module
program fe1nvol12
use mod
integer :: error = 0
call sub(6,error)
if (error .ne. 0) then
print *,'NG: snem0601_012'
end if
print *,'pass: snem0601_012'
end program fe1nvol12
```
the following output is produced:
```bash
$ flang-new -fc1 snem0601_012_.f90
/noback/93u/Sandbox/issue_58973_volatile_dummy_arg/snem0601_012_.f90:21:12: warning: actual argument associated with VOLATILE dummy argument 'm6=' is not a variable
call sub(6,error)
^
```
Reviewed By: clementval, klausler
Differential Revision: https://reviews.llvm.org/D139134
An unlimited polymorphic entity is considered to have a derived category
in its dynamic type but no type descriptor. Avoid a nullptr dereference when
an unlimited polymorphic type needs to be generated.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139923
When emboxing an entity to a polymorphic box, use the input type to
compute the type code and element size as the box type is too generic.
When reboxing a polymorphic box, get this information from the input
box.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139916
Doing a pointer assignment to another pointer which is a derived type component
could result in the bound information being lost, potentially leading to
incorrect array accesses. Fix this by trying to retain the bound info during
the assignment.
Fixes#57441
Differential Revision: https://reviews.llvm.org/D139800
Another attempt to skip the fast-math linker test on powerpc. The test
has to be skipped because there is no crtfastmath.o on powerpc.
Change recommended by Amy Kwan <amyk>.
See https://reviews.llvm.org/D138675
The fastmath test checks that crtfastmath.o is added between crtbeginS.o
and crtendS.o. On some systems, crtend is called crtend.o - match these
too.
Related to https://reviews.llvm.org/D138675
pointer association to a polymorphic pointer needs to potentially
update the element size in the descriptor. Update the pointer association
to polymoprhic pointer with a runtime call to PointerAssociate.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139825
The fastmath test checks that crtfastmath.o is added between crtbeginS.o
and crtend.o. On some systems the first file is instead called
crtbegin.o - match these too.
Related to https://reviews.llvm.org/D138675
clang -cc1 accepts -Ofast. I did not add it to flang -fc1 because this
seems redundant because the compiler driver will always resolve -Ofast
into -O3 -ffast-math (I added a test for this).
-menable-infs is removed from the frontend-forwarding test because if
all of the fast-math component flags are present, these will be resolved
into the fast-math flag. Instead -menable-infs is tested in the
fast-math test.
Specifying -ffast-math to the compiler driver causes linker invocations
to include crtfastmath.o.
RFC: https://discourse.llvm.org/t/rfc-the-meaning-of-ofast/66554
Differential Revision: https://reviews.llvm.org/D138675
Polymorphic entities are already emboxed. Just update
the code to use `BaseBoxType` instead of `BoxType`.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139707
