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
The semantic checks and runtime have been supported. This supports the
lowering of intrinsic ABORT.
`gfortran` prints a backtrace before abort, unless `-fno-backtrace` is
given. This is good to use. The intrinsic BACKTRACE is not supported
yet, so add TODO in the runtime.
This extention is needed in SPEC2017 521.wrf_r in
https://github.com/llvm/llvm-project/issues/55955.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D130439
As Fortran 2018 18.2.3.6, the intrinsic `c_loc(x)` gets the C address
of argument `x`. It returns the scalar of type C_PTR. As defined in
iso_c_binding in `flang/module/__fortran_builtins.f90`, C_PTR is the
derived type with only one component of integer 64.
This supports the lowering of intrinsic module procedure `c_loc` by
converting the address of argument into integer 64, where the argument
is lowered as Box and the address is generated using fir.box_addr.
The lowering of intrinsic `c_funloc` has the similar characteristic and
will be supported later.
The execution tests for various data types are in issue
https://github.com/llvm/llvm-project/issues/56552.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D129659
This patch refactors the runtime support for GET_COMMAND_ARGUMENT to
have a single entry point instead of 2. It also updates lowering
accordingly.
This makes it easier to handle dynamically optional arguments. See also
https://reviews.llvm.org/D118777
Differential Revision: https://reviews.llvm.org/D130475
The fp128 in llvm.round and llvm.trunc is not supported in X86_64 for
now. Revert the support. To support quad precision for llvm.round and
llvm.trunc, it may should be supported using runtime.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D130556
As Fortran 2018 16.9.169, the argument of selected_int_kind is integer
scalar, and result is default integer scalar. The constant expression in
this intrinsic has been supported by folding the constant expression.
This supports lowering and runtime for variables in this intrinsic.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D129959
As Fortran 2018 16.9.170, the argument of `selected_real_kind` is integer
scalar, and result is default integer scalar. The constant expression in
this intrinsic has been supported by folding the constant expression.
This supports lowering this intrinsic for variables using runtime.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D130183
For aint/anint, LLVM conversion operations llvm.trunc and llvm.round
can support the edge case of aint(-0.) and anint(-0.). The output is -0.
and it is the same of `gfortran` and `classic flang`, while the output
of `ifort` is 0.. The `real(10)/real(16)` is not supported before.
Support it and remove the runtime functions for aint/anint.
For nint, `gfortran`, `ifort`, and LLVM Flang using llvm.lround have
different results when the magnitude of argument is more than the max of
result value range. So delay its support in lowering after more
investigations.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D130024
This commit changes how math intrinsics are lowered: we, first,
try to lower them into MLIR operations or libm calls via
mathOperations table and only then fallback to pgmath runtime calls.
The pgmath fallback is needed, because mathOperations does not
support all intrinsics that pgmath supports. The main purpose
of this change is to get rid of llvmIntrinsics table so that
we do not have to update both llvmIntrinsics and mathOperations
when adding new intrinsic support.
mathOperations lowering should phase out pgmath lowering, when
more operations are available (e.g. power operations being
added in D129809 and D129811; complex type operations from
Complex dialect).
Differential Revision: https://reviews.llvm.org/D130129
Lower F08 shift (shiftl, shiftr, shifta) and combined shift (dshiftl, dshiftr)
intrinsics. The combined shift intrinsics are implemented using the
definitions of shiftl and shiftr as described by the standard.
For non-conformant arguments to the shift intrinsics, the implementation tries
to replicate the behavior of other compilers if most of the other behave
consistently.
Differential Revision: https://reviews.llvm.org/D129316
Lower F08 bit population count intrinsics popcnt, poppar, leadz and trailz. popcnt, leadz and trailz are implemented using the corresponding MLIR math intrinsics. poppar is implemented in terms of popcnt.
Differential Revision: https://reviews.llvm.org/D129584
mathOperations should now support all intrinsics that are handled
by the llvmIntrinsics table + `tan` lowered as Math dialect operation +
f128 flavor of abs.
I am going to flip the default to late math lowering after this change,
but still keep the fallback via pgmath. This will allow getting rid
of the llvmIntrinsics table and continue populating
only the mathOperations table, otherwise, updating both tables
seems to be inconvenient.
Differential Revision: https://reviews.llvm.org/D130048
This patch implements lowering for the F08 bitwise comparison intrinsics
(BGE, BGT, BLE and BLT).
This does not create any runtime functions since the functionality is
simple enough to carry out in IR.
The existing semantic check has been changed because it unconditionally
converted the arguments to the largest possible integer type. This
resulted in the argument with the smaller bit-size being sign-extended.
However, the standard requires the argument with the smaller bit-size to
be zero-extended.
Reviewed By: klausler, jeanPerier
Differential Revision: https://reviews.llvm.org/D127805
The check to see if the arguments for the MIN/MAX intrinsics were of CHARACTER
type was not handling assumed length characters. In this case, the FIR type is
"!fir.ref<!fir.char<1,?>>".
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D128922
Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
The original assertion is not necessarily correct since the shape
argument may involve a slice of an array (an expression) and not a whole
vector with constant length. In the presence of a slice operation, the
size must be computed (left as a TODO for now).
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D128894
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Added new -lower-math-early option that defaults to 'true' that matches
the current math lowering scheme. If set to 'false', the intrinsic math
operations will be lowered to MLIR operations, which should potentially
enable more MLIR optimizations, or libm calls, if there is no corresponding
MLIR operation exists or if "precise" mode is requested.
The generated math MLIR operations are then converted to LLVM dialect
during codegen phase.
The -lower-math-early option is not exposed to users currently. I plan to
get rid of the "early" lowering completely, when "late" lowering
is robust enough to support all math intrinsics that are currently
supported via pgmath. So "late" mode will become default and -lower-math-early
option will not be needed. This will effectively eliminate the mandatory
dependency on pgmath in Fortran lowering, but this is WIP.
Differential Revision: https://reviews.llvm.org/D128385
In merge FSOURCE and TSOURCE must have the same Fortran dynamic types,
but this does not imply that FSOURCE and TSOURCE will be lowered to the
same MLIR types. For instance, TSOURCE may be a character expression
with a compile type constant length (!fir.char<1,4>) while FSOURCE may
have dynamic length (!fir.char<1,?>).
Cast FSOURCE to TSOURCE MLIR types to handle these cases.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D128507
Co-authored-by: Jean Perier <jperier@nvidia.com>
LBOUND with a non constant DIM argument use the runtime to allow runtime
verification of DIM <= RANK. The interface uses a descriptor. This caused
undefined behavior because the runtime believed it was seeing an explicit
shape arrays with zero extent and returned `1` (the runtime descriptor
does not allow making a difference between an explicit shape and an
assumed size. Assumed size are not meant to be described by runtime
descriptors).
Fix the issue by setting the last extent of assumed size to `1` when
creating the descriptor to inquire about the LBOUND with the runtime.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D128509
Co-authored-by: Jean Perier <jperier@nvidia.com>
* Make Semantics test doconcurrent01.f90 an expected failure pending a fix
for a problem in recognizing a PURE prefix specifier for a specific procedure
that occurs in new intrinsic module source code,
* review update
* review update
* Increase support for intrinsic module procedures
The f18 standard defines 5 intrinsic modules that define varying numbers
of procedures, including several operators:
2 iso_fortran_env
55 ieee_arithmetic
10 ieee_exceptions
0 ieee_features
6 iso_c_binding
There are existing fortran source files for each of these intrinsic modules.
This PR adds generic procedure declarations to these files for procedures
that do not already have them, together with associated specific procedure
declarations. It also adds the capability of recognizing intrinsic module
procedures in lowering code, making it possible to use existing language
intrinsic code generation for intrinsic module procedures for both scalar
and elemental calls. Code can then be generated for intrinsic module
procedures using existing options, including front end folding, direct
inlining, and calls to runtime support routines. Detailed code generation
is provided for several procedures in this PR, with others left to future PRs.
Procedure calls that reach lowering and don't have detailed implementation
support will generate a "not yet implemented" message with a recognizable name.
The generic procedures in these modules may each have as many as 36 specific
procedures. Most specific procedures are generated via macros that generate
type specific interface declarations. These specific declarations provide
detailed argument information for each individual procedure call, similar
to what is done via other means for standard language intrinsics. The
modules only provide interface declarations. There are no procedure
definitions, again in keeping with how language intrinsics are processed.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D128431
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
system_clock intrinsic calls with dynamically optional arguments
Modify intrinsic system_clock calls to allow for an argument that is optional
or a disassociated pointer or an unallocated allocatable. A call with such an
argument is the same as a call that does not specify that argument.
Rename (genIsNotNull -> genIsNotNullAddr) and (genIsNull -> genIsNullAddr)
and add a use of genIsNotNullAddr.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D127616
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Remove a backwards dependence from Optimizer -> Lower by moving Todo.h
to the optimizer and out of lowering.
This patch is part of the upstreaming effort from fir-dev branch.
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D127292
The lowering code was mistakenly assuming that the second argument
in the signature provided by semantics is the DIM argument. This
caused calls with a KIND argument but no DIM to be lowered as if the
KIND argument was DIM.
Differential Revision: https://reviews.llvm.org/D124243
In some case the lowering of `ichar` is generating an `arith.extui` operation
with the same from/to type. This operation do not accept from/to types to be
the same. If the from/to types are identical, we do not generate the extra
operation.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D124107
Handle dynamic optional argument in GET_COMMAND_ARGUMENT and GET_ENVIRONMENT_VARIABLE
(previously compiled but caused segfaults). The previous code
handled static presence/absence aspects, but not when an absent dummy optional was
passed to one of the optional intrinsic arguments.
Simplify the runtime call lowering to simply lower the runtime call without
dealing with optionality there. This keeps the optional handling logic in
IntrinsicCall.cpp.
Note that the new code will generate some extra "if (not null addr )/then/else"
when the actual arguments are always there at runtime. That makes the implementation
a lot simpler/safer, and I think it is OK for now (I do not expect these runtime
function to be called in hot loop nests).
Differential Revision: https://reviews.llvm.org/D123388
The actual argument passed to STATUS may be a dummy OPTIONAL or a
disassociated POINTER/unallocated ALLOCATABLE.
Differential Revision: https://reviews.llvm.org/D123380
isAbsent/isPresent helpers only give information about static presence
of intrinsic arguments. Many intrinsic arguments optionality is dynamic
(an absent dummy can legally be passed to these intrinsics). This
requires a different handling (like `handleDynamicOptional`).
Rename the helpers to avoid misleading coder/reader into thinking all
optionality cases are covered by them.
Differential Revision: https://reviews.llvm.org/D123378
Enable lowering to the relaxed and precise variants in the pgmath
library.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D122484
Follow up of https://reviews.llvm.org/D121488. Ensure lower bounds
are `1` when the related dimension extent is zero. Note that lower
bounds from descriptors are now guaranteed to fulfill this property
after the runtime/codegen patches.
Also fixes explicit shape array extent lowering when instantiating
variables to deal with negative extent cases (issue found while testing
LBOUND edge case). This notably caused allocation crashes when dealing
with automatic arrays with reversed bounds or negative size
specification expression. The standard specifies that the extent of such
arrays is zero. This change has some ripple effect in the current lit
tests.
Add move two helpers as part of this change:
- Add a helper to tell if a fir::ExtendedValue describes an assumed size
array (last dimension extent is unknown to the compiler, both at compile
time and runtime).
- Move and share getIntIfConstant from Character.cpp so that it can be
used elsewhere (NFC).
Differential Revision: https://reviews.llvm.org/D122467
The intrinsic returns the character located at the position requested
in the ASCII sequence. The intrinsic is lowered to inline FIR code.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D122480
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds the lowering for the `mvbits`
intrinsic.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122412
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch rearranges the generator functions for various intrinsics.
The rearrangement will help to identify any missing functionality.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122334
The intrinsic computes the sin, cosine values. By default they are lowered
to runtime calls to the pgmath library, for llvm lowering they are
lowered to llvm intrinsics. The generic and llvm lowering does not
lower floating point types with kind greater than 8, the llvm lowering
does not support the complex types.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D122320
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
The intrinsic computes the tan and hyperbolic sin, cosine values. By
default they are lowered to runtime calls to the math library. Not all
types are supported currently. The generic and llvm lowering does not
lower floating point types with kind greater than 8, the llvm lowering
does not support the complex types.
Note: tanh is not present in fir-dev hence ignoring for now. We can add
support after upstreaming is complete. sin and cos will come in separate
patches since they have llvm intrinsic lowering.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122264
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: William Moses <gh@wsmoses.com>
The intrinsic computes the square root for real and complex numbers. By
default they are lowered to runtime calls to libpgmath. With the llvm
option, it can be lowered to llvm intrinsics (not all types .eg. complex
are supported for llvm lowering).
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D122018
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
In FIR, we want to wrap function pointers in a special box known as a
boxproc value. Fortran has a limited form of dynamic scoping
[https://tinyurl.com/2p8v2hw7] between "host procedures" and "internal
procedures". There are a number of implementations possible.
Boxproc typed values abstract away the implementation details of when a
function pointer can be passed directly (as a raw address) and when a
function pointer has to account for the presence of a dynamic scope.
When lowering Fortran syntax to FIR, all function pointers are emboxed
as boxproc values.
When creating LLVM IR, we must strip away the abstraction and produce
low-level LLVM "assembly" code. This patch implements that
transformation as converting the boxproc values to either raw function
pointers or executable trampolines on the stack as needed. The
trampoline then captures the dynamic scope context within an executable
thunk that can be passed instead of the function's raw address.
Some extra handling is required for Fortran functions that return a
character value to deal with LEN values here.
Some of the code in Bridge.cpp and ConvertExpr.cpp and be re-arranged to
faciliate the upstreaming effort.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122223
Co-authored-by: mleair <leairmark@gmail.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
The intrinsic computes the exponent, log real and complex numbers and
log10 for real numbers. By default they are lowered to runtime calls to
libpgmath. kind=10 and 16 are not supported. With the llvm option, it
can be lowered to llvm intrinsics (not all types .eg. complex are
supported for llvm lowering).
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122132
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: William S Moses <gh@wsmoses.com>
This patch adds lowering for procedure designator.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122153
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds support for lowering of the `ior` intrinsic from
Fortran to the FIR dialect of MLIR.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D121928
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds support for lowering of the `{l|u}bound` intrinsics from
Fortran to the FIR dialect of MLIR. Note that `ubound` is already
supported, but the test was missing (added here).
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D121926
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
This patch adds support for lowering of the `merge` intrinsics from
Fortran to the FIR dialect of MLIR.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D121924
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Mark Leair <leairmark@gmail.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
These intrinsics returns the distance to the nearest real number and
their reciprocal. They are lowered to flang runtime calls.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D121832
Co-authored-by: Mark Leair <leairmark@gmail.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds lowering for the following numeric intrinsics:
- aint
- anint
- cmplx
- conjg
- dble
- dprod
- sign
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D121917
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
V Donaldson