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
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
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 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>
The repeat intrinsic creates ncopies of a string. The lowering is to
a runtime call to a function in the flang library. The runtime allocates
the buffer to store the result string. This buffer is freed by code
added in the 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: clementval
Differential Revision: https://reviews.llvm.org/D121880
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds lowering for command and environment
related intrinsics:
- `get_command_argument`
- `get_environment_variable`
- `command_argument_count`
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121909
Co-authored-by: Josh Mottley <Josh.Mottley@arm.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds lowering for couple of intrinsics:
- `btest`
- `ceiling`
- `nearest`
- `scale`
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121885
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: AlexisPerry <aperry@lanl.gov>
This patch adds lowering for the `present` intrinsic.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121884
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds lowering for the `exit`
intrinsic.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121882
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Josh Mottley <Josh.Mottley@arm.com>
This patch adds lowering for somw array related intrinsics:
- `reshape`
- `spread`
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D121841
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
This patch adds lowering for some character related
intrinsics:
- `scan`
- `verify`
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121842
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This removes any potential confusion with the `getType` accessors
which correspond to SSA results of an operation, and makes it
clear what the intent is (i.e. to represent the type of the function).
Differential Revision: https://reviews.llvm.org/D121762
This patch adds lowering for some numeric related
intrinsics:
- `exponent`
- `floor`
- `fraction`
- `mod`
- `modulo`
- `nint`
- `not`
- `product`
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D121828
Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
