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
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.
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
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
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
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.
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
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
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
In elemental procedure lowering the passed object is always emboxed. The current code
was not correctly dealing with scalar derived-type used as passed object.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139667
This patch adds support for lowering intrinsics that have no dynamic
optionality aspects to handle and that requires argument to be lowered
to value, addr, or box.
It uses the current intrinsic lowering framework that can be re-used in
HLFIR to start with. HLFIR operations for charater/transformational
intrinsics will be added as needed from an optimization point of view.
The current approach will still create temporary variables for their
value directly in lowering.
Later patch will still need to add:
- support for dynamically optional arguments
- inquires
- "moving" the in memory computation of character and transformational
intrinsics to hlfir.expr. This is not needed from a semantic point of
view, but will help optimizing and will probably be required inside
hlfir.elemental returning characters so that the returned element
type is an hlfir.expr and match the result type of later hlfir.apply.
Differential Revision: https://reviews.llvm.org/D139613
When call an elemental subroutine with a monomorphic or polymorphic
passed object, the iteration shape could not be computed. Use the
passed object to infer the implicit iteration shape so the loop
can be constructed.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139635
The passed object is placed in the passed arguments by semantics.
When the TBP to be called is an elemental subroutine or function it has to be
handled accordingly.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139537
Polymorphic entities are always emboxed. This patch
handles host association of polyrmophic entities as passed object.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139423
Support fir.class in genScalarUserDefinedAssignmentCall so
emboxing is done correctly.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139435
For now at least, the plan is to keep hlfir.expr usage limited as
sub-expression operand, assignment rhs, and a few other contexts (
e.g. Associate statements). The rest of lowering (statements lowering
in the bridge) will still expect to get and manipulate characters and
arrays in memory. That means that hlfir.expr must be converted to
variable in converter.genExprAddr/converter.genExprBox.
This is done using an hlfir.associate, and generating the related
hlfir.end_associate in the statement context.
hlfir::getFirBase of is updated to avoid bringing in the HLFIR
fir.boxchar/fir.box into FIR when the entity was created with
hlfir::AssociateOp.
Differential Revision: https://reviews.llvm.org/D139328
When generating character assignment operations, the generic code
generates some code to handle truncation and padding when the length
differ at runtime. A bypass already exists when the length are compile
time constant and match, but it was not used for the trivial case where
the RHS and LHS length is the same SSA value. In such case, even though,
the length is not know at compile time, it is known to be the same.
This will simplify the code creating character temporaries from a
variable in HLFIR that will use this assignment code.
Note that this probably has little impact on performance (llvm may be clever enough
to later catch that for us). But it makes the generated IR a lot more readable at
little cost.
Differential Revision: https://reviews.llvm.org/D139330
The implementation follows the pattern used in comparable intrinsics.
Change the runtime API for Norm2 so it does not expect a mask argument
since the Norm2 intrinsic does not accept a mask in Fortran.
Differential Revision: https://reviews.llvm.org/D138150
In order to emit overflow warnings from assignment statements whose
right-hand sides are constants that undergo conversions, run the
right-hand sides of assignments through constant folding after the
conversions have been made explicit in expression analysis.
Differential Revision: https://reviews.llvm.org/D139151
Runtime is expecting a 1d array. This patch fixes the generation
of the array holding the bounds to be passed to the runtime function call.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139324
Lower pointer assignment with remapping involving polymorphic entities
to runtime call to PointerAssociateRemapping.
For the time being all pointer assignment involcing polymorphic entities are
done with the runtime call. When lhs is not unlimited polymorphic
we might be able to do it inlined as well.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139198
The only special thing that is needed is to update the bridge symbol
lookup to deal with the HLFIR symbol lookup (symbols are mapped to
fir::FortranVariableInterface operations, not Fortran::Lower::SymbolBox).
Differential Revision: https://reviews.llvm.org/D139201
The semantics of many transformational intrinsic functions, especially
reductions like SUM(), are determined by the static presence or absence
of a DIM= argument. In the case of an actual DIM= argument that is
syntactically present but could be dynamically absent at execution time
(due to being OPTIONAL, POINTER, or ALLOCATABLE), f18 should emit some
kind of diagnostic message.
Other compilers either ignore this possibility or treat it as a hard
error; neither really seems correct, so let's do something more nuanced.
For cases where the dynamic absence of a value for DIM doesn't pose
as much of a risk because it lowering is going to assume that it's
equal to 1 anyway, emit only a portability warning.
For other cases where the generated code or runtime support library
will need the value of DIM= during execution, emit a warning that
the use of an OPTIONAL/POINTER/ALLOCATABLE variable or component
here is dicey and should be reconsidered.
While here, also catch bad constant DIM= values.
Differential Revision: https://reviews.llvm.org/D139155
Lower not, negate, and complex component to HLFIR.
Parentheses is the only remaining operation, but needs some
care/thinking to properly deal with character/derived variables.
Differential Revision: https://reviews.llvm.org/D139186
SELECT TYPE lower and conversion was not handling
`character` type guard. This add support for it.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139106
Update BinaryOp<T>::gen so that const T& is threaded and some
operation knowledge that is not encoded by the type T or the arguments
can be used. For Extremum, it is the order (Greater or Lesser) that is
required, but this will also be required for evaluate::Relational.
Differential Revision: https://reviews.llvm.org/D139124
Use recently added hlfir.associate/hlfir.end_associate to deal
with the cases where the actual argument is an expression.
Differential Revision: https://reviews.llvm.org/D139009
Record type was not correctly retrived so the runtime call was not
produced correctly.
Fix how the record type is retrived so the correct call is
produced.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139084
In D139019 the assumption was made that the rhs was also the MutableBox
but this is not a constraint. Use genExprBox instead. Also the allowed
conversion in D139019 was not correct. Remoed it since it is not needed anymore.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139081
Pointer association with an unlimited polymorphic pointer on the lhs
requires more than just updating the base_addr. Delegate the association to
the runtime function `PointerAssociation`.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139019
