Result must carry the polymorphic type information
from the source.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D142095
In lowering to hlfir, no clean-up was added yet for
the created hlfir.elemental. Add the needed hlfir.destroy.
Regarding transformational lowering, clean-ups were created because
they are lowered in memory, but this is inconvenient because this
prevented lowering to hlfir from "moving" the created variable to
an expression. Add a new entry point in IntrinsicCall.h that keeps
track of whether or not the returned storage needs to be deallocated,
but does not insert the deallocation in the StatementContext.
This allows using the newly added hlfir.as_expr "move" aspect to be
used and save creating a copy.
Depends on D141839
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D141841
Use asBox so no simply contiguous argument do not issue a copy and also
support polymorphic entity out of the box.
Depends on D141667
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141678
When creating temporary from a polymorphic entity, its dynamic type
information must be carried over to the temporary.
This patch updates createTempMutableBox to support passing a source_box
from which the information will be carried over.
This is tested on the spread intrinsic and follow-up patches will updates
other temporary creation where needed.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141667
The current intrinsic call lowering contains a lot of repetitive
patterns when it comes to dealing with temporary allocatable
results allocated by the runtime that need to be dereferenced and
for which a clean-up (free) must be scheduled in the StatementContext.
For HLFIR lowering, I will need to deal with the clean-up in a different
way since the results will be "moved" into expression nodes and
the clean-up will be inserted in bufferization after the last hlfir.expr
usage. Centralizing the clean-up code will make that easier, and is
regardless of this motivation a quality improvement.
Some static helpers had to be moved to IntrinsicBuilder method so that
they could call the readAndAddCleanUp code.
Differential Revision: https://reviews.llvm.org/D141669
This supports the lowering of intrinsic IS_CONTIGUOUS for array argument.
The argument of assumed rank is not supported since it is not implemented
yet as the procedure argument. Add TODO for it.
Reviewed By: PeteSteinfeld, jeanPerier
Differential Revision: https://reviews.llvm.org/D141212
Add implementation and loweirng for the extends_type_of
intrinsic.
The standard mentions this: otherwise if the dynamic type of A or MOLD is
extensible, the result is true if and only if the dynamic type of A is an
extension type of the dynamic type of MOLD. Which could be interpreted that
`extends_type_of(a, a)` could be false since a type is not an extension of
itself. Gfortran result for this is `true` so the same behavior is applied
here as well.
Depends on D141364
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141376
The test performed by same_type_as does not consider kind type
parameters. If an exact match is not found, the name of the
derived type is compared. The name in the runtime info does not include
the kind type parameters as it does in the mangled name.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141364
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.
The motivation is to have it accessible in HLFIROps.cpp to
use it in hlfir.set_length builder to build the result length
type as best as possible.
Differential Revision: https://reviews.llvm.org/D140214
I kept the possibility to use pgmath in constant folding
just in case. We can remove it later, if it is proven to be redundant.
Differential Revision: https://reviews.llvm.org/D140236
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
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
Clang uses signext/zeroext attributes for integer arguments shorter than
the default 'int' type on a target. So Flang has to match this for functions
from Fortran runtime and also for BIND(C) routines. This patch implements
ABI adjustments only for Fortran runtime calls. BIND(C) part will be done
separately.
This resolves https://github.com/llvm/llvm-project/issues/58579
Differential Revision: https://reviews.llvm.org/D137050
The implementation follows the patterns established by the lowering of other
similar intrinsics.
In addition to the code for lowering, the DoTotalReduction template had to be
fixed to correctly break when signaled to do so by the accumulator function.
Differential Revision: https://reviews.llvm.org/D138140
As Fortran 2018 16.9.82, all the arguments of GET_COMMAND are optional.
When they are all absent, do nothing so to be consistent with gfortran
and ifort. The semantic analysis and runtime have been supported.
This intrinsic was introduced from F2003, and this supports the lowering
of it.
Reviewed By: PeteSteinfeld, jeanPerier
Differential Revision: https://reviews.llvm.org/D137887
As Fortran 2018 16.9.82, all the arguments of GET_COMMAND are optional.
When they are all absent, do nothing so to be consistent with gfortran
and ifort. The semantic analysis and runtime have been supported.
This intrinsic was introduced from F2003, and this supports the lowering
of it.
Reviewed By: PeteSteinfeld, jeanPerier
Differential Revision: https://reviews.llvm.org/D137887
Clang uses signext/zeroext attributes for integer arguments shorter than
the default 'int' type on a target. So Flang has to match this for functions
from Fortran runtime and also for BIND(C) routines. This patch implements
ABI adjustments only for Fortran runtime calls. BIND(C) part will be done
separately.
This resolves https://github.com/llvm/llvm-project/issues/58579
Differential Revision: https://reviews.llvm.org/D137050
This patch lowers the complex operations supported by the MLIR complex
dialect to those operations rather than libm. When the math runtime flag
is set to precise, libm lowering is used instead.
Differential Revision: https://reviews.llvm.org/D135882
As Fortran 2018 18.2.3.2, the arguments of C_ASSOCIATED have the same
type, a scalar of type C_PTR or C_FUNPTR, and the result has the default
logical scalar type. The interface is defined with two module procedures
c_associated_c_ptr/c_associated_c_funptr in flang/module/iso_c_binding.
The result is false if the first argument is a C null pointer. If the
second argument is present, the result is true only if the two arguments
are equal. Support the lowering by comparing the C pointer address
values of two arguments if the second argument is dynamically present
and comparing the C pointer address value of the first argument with the
value 0.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136419
This patch adds a cpowi function to the flang runtime, and switches
to using that function instead of pgmath for complex number to
integer power operations.
Differential Revision: https://reviews.llvm.org/D134889
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
This patch changes the handling of complex number intrinsics that
have C libm equivalents to call into those instead of calling the
external pgmath library.
Currently complex numbers to integer powers are excluded as libm
has no powi equivalent function.
Differential Revision: https://reviews.llvm.org/D134655
This calls the corresponding runtime functions when appropriate. The implementation
follows the pattern of the SUM and PRODUCT intrinsics.
Differential Revision: https://reviews.llvm.org/D129616
The TARGET argument of ASSOCIATED has a special lowering to deal with
POINTER and ALLOCATABLE optional actual arguments because they may be
dynamically absent. The previous code was doing a ternary
(mlir::SelectOp) to deal with this case, but generated invalid
code for the unused argument (loading a nullptr fir.ref<fir.box>). This
was not detected until D133779 was merged and modified how fir.load are
lowered to LLVM for fir.box types.
Replace the select by a proper if to prevent the fir.load from being
reachable in context where it should not.
Differential Revision: https://reviews.llvm.org/D134174
C_F_POINTER was added in https://reviews.llvm.org/D132303, but the code
assumed that SHAPE would always be an explicit shape with compile time
constant rank. It can actually be an assumed shape, or an explicit shape
with non compile time constant rank. Get the rank from FPTR pointer
instead.
Differential Revision: https://reviews.llvm.org/D133347
As Fortran 2018 18.2.3.3, the intrinsic module procedure
C_F_POINTER(CPTR, FPTR [, SHAPE]) associates a data pointer with the
target of a C pointer and specify its shape. CPTR shall be a scalar of
type C_PTR, and its value is the C address or the result of a reference
to C_LOC. FPTR is one pointer, either scalar or array. SHAPE is a
rank-one integer array, and it shall be present if and only if FPTR is
an array.
C_PTR is the derived type with only one component of integer 64, and the
integer 64 component value is the address. Build the right "source"
fir::ExtendedValue based on the address and shape, and use
associateMutableBox to associate the pointer with the target of the C
pointer.
Refactor the getting the address of C_PTR to reuse the code.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D132303
This patch update the lowering of the shifta intrinsic to match
the behvior of gfortran. When the SHIFT value is equal to the
integer bitwidth then we handle it differently.
This is due to the operation used in lowering (`mlir::arith::ShRSIOp`)
that lowers to `ashr`.
Before this patch we have the following results:
```
SHIFTA( -1, 8) = 0
SHIFTA( -2, 8) = 0
SHIFTA( -30, 8) = 0
SHIFTA( -31, 8) = 0
SHIFTA( -32, 8) = 0
SHIFTA( -33, 8) = 0
SHIFTA(-126, 8) = 0
SHIFTA(-127, 8) = 0
SHIFTA(-128, 8) = 0
```
While gfortran is giving this:
```
SHIFTA( -1, 8) = -1
SHIFTA( -2, 8) = -1
SHIFTA( -30, 8) = -1
SHIFTA( -31, 8) = -1
SHIFTA( -32, 8) = -1
SHIFTA( -33, 8) = -1
SHIFTA(-126, 8) = -1
SHIFTA(-127, 8) = -1
SHIFTA(-128, 8) = -1
```
With this patch flang and gfortran have the same behavior.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D133104
We used to select the runtime function based on the first argument's
type, which was not correct behavior. The selection is done using
the result type now.
Differential Revision: https://reviews.llvm.org/D133032
As Fortran 2018 18.2.3.5, the intrinsic c_funloc(x) gets the C address
of argument x. It returns the scalar of type C_FUNPTR. As defined in
iso_c_binding in flang/module/__fortran_builtins.f90, C_FUNPTR is the
derived type with only one component of integer 64.
This follows the implementation of https://reviews.llvm.org/D129659. The
argument is lowered as ProcBox and the address is generated using
fir.box_addr.
Reviewed By: jeanPerier, clementval
Differential Revision: https://reviews.llvm.org/D132273
Apply lower bounds before call to the ubound runtime function.
This is similary done in genLBound.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D133001
Lower F08 parity intrinsic. This largely follows the implementation of the ANY
and ALL intrinsics which are related.
Differential Revision: https://reviews.llvm.org/D129788
The code generated for this version of the intrinsic is broken. I'm
marking it as a "TODO" for now so that people don't get unannounce bad
results.
Differential Revision: https://reviews.llvm.org/D132082
Add a proper TODO for the REDUCE instrinsic instead of crashing.
Reviewed By: PeteSteinfeld, vdonaldson
Differential Revision: https://reviews.llvm.org/D132020
With this change all supported pgmath functions for non-complex
data types are replaced with either libm calls or MLIR operations,
except for MOD and some flavors of POW, which are going to be addressed
by other commits.
At the current stage a few math intrinsics are lowered into libm calls
always. When appropriate MLIR operation are available, the table can be
updated to generate them.
This change removes dependency on pgmath mod, and also allows
Fortran runtime to issue a diagnostic message in case of zero
denominator.
Differential Revision: https://reviews.llvm.org/D131192
