History log of /llvm-project-15.0.7/flang/lib/Lower/IntrinsicCall.cpp (Results 1 – 25 of 104)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# 418d2338 26-Jul-2022 Peixin Qiao <[email protected]>

[flang] Remove fp128 support for llvm.round and llvm.trunc

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

[flang] Remove fp128 support for llvm.round and llvm.trunc

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

show more ...


# f532c072 25-Jul-2022 Peixin Qiao <[email protected]>

[flang] Support intrinsic `selected_int_kind` for variables

As Fortran 2018 16.9.169, the argument of selected_int_kind is integer
scalar, and result is default integer scalar. The constant expressi

[flang] Support intrinsic `selected_int_kind` for variables

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

show more ...


# 57e3fa38 25-Jul-2022 Peixin Qiao <[email protected]>

[flang] Support lowering intrinsic `selected_real_kind` for variables

As Fortran 2018 16.9.170, the argument of `selected_real_kind` is integer
scalar, and result is default integer scalar. The cons

[flang] Support lowering intrinsic `selected_real_kind` for variables

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

show more ...


# 3ccd4ce2 23-Jul-2022 Peixin Qiao <[email protected]>

[flang] Support aint/anint for 80/128 bit in lowering

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.
an

[flang] Support aint/anint for 80/128 bit in lowering

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

show more ...


# f5759add 19-Jul-2022 Slava Zakharin <[email protected]>

[flang] Try to lower math intrinsics to math operations first.

This commit changes how math intrinsics are lowered: we, first,
try to lower them into MLIR operations or libm calls via
mathOperations

[flang] Try to lower math intrinsics to math operations first.

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

show more ...


# 71ee3570 22-Jul-2022 Tarun Prabhu <[email protected]>

[flang] Lower F08 mask intrinsics

Lower F08 maskl and maskr intrinsics.

Differential Revision: https://reviews.llvm.org/D129296


# 72ac3e90 22-Jul-2022 Tarun Prabhu <[email protected]>

[flang] Lower F08 shift intrinsics

Lower F08 shift (shiftl, shiftr, shifta) and combined shift (dshiftl, dshiftr)
intrinsics. The combined shift intrinsics are implemented using the
definitions of s

[flang] Lower F08 shift intrinsics

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

show more ...


# ccfee46b 22-Jul-2022 Tarun Prabhu <[email protected]>

[flang] Lower F08 bit population count intrinsics

Lower F08 bit population count intrinsics popcnt, poppar, leadz and trailz. popcnt, leadz and trailz are implemented using the corresponding MLIR ma

[flang] Lower F08 bit population count intrinsics

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

show more ...


# b6fef088 21-Jul-2022 Tarun Prabhu <[email protected]>

[flang] Lower F08 merge_bits intrinsic.

Lower F08 merge_bits intrinsic.

Differential Revision: https://reviews.llvm.org/D129779


# fd4afa7a 18-Jul-2022 Slava Zakharin <[email protected]>

[flang] Support late math lowering for intrinsics from the llvm table.

mathOperations should now support all intrinsics that are handled
by the llvmIntrinsics table + `tan` lowered as Math dialect o

[flang] Support late math lowering for intrinsics from the llvm table.

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

show more ...


# 7709f12e 19-Jul-2022 Tarun Prabhu <[email protected]>

Bitwise comparison intrinsics

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

Bitwise comparison intrinsics

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

show more ...


# 11c43cd2 30-Jun-2022 Valentin Clement <[email protected]>

[flang] Fix "not yet implemented" message for CHARACTER MIN/MAX

The check to see if the arguments for the MIN/MAX intrinsics were of CHARACTER
type was not handling assumed length characters. In th

[flang] Fix "not yet implemented" message for CHARACTER MIN/MAX

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 <[email protected]>

show more ...


# 540a76f0 30-Jun-2022 Valentin Clement <[email protected]>

[flang] Convert assertion to a TODO

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 le

[flang] Convert assertion to a TODO

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 <[email protected]>

show more ...


# 6c487002 30-Jun-2022 Valentin Clement <[email protected]>

[flang][NFC] Revert message to not implemented yet


# 9f356579 22-Jun-2022 Slava Zakharin <[email protected]>

[flang] Lower Fortran math intrinsic operations into MLIR ops or libm calls.

Added new -lower-math-early option that defaults to 'true' that matches
the current math lowering scheme. If set to 'fals

[flang] Lower Fortran math intrinsic operations into MLIR ops or libm calls.

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

show more ...


# 56c81d25 24-Jun-2022 Valentin Clement <[email protected]>

[flang][lowering] handle MERGE with different FSOURCE and TSOURCE types

In merge FSOURCE and TSOURCE must have the same Fortran dynamic types,
but this does not imply that FSOURCE and TSOURCE will b

[flang][lowering] handle MERGE with different FSOURCE and TSOURCE types

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 <[email protected]>

show more ...


# 4489ef8e 24-Jun-2022 Valentin Clement <[email protected]>

[flang] Fix LBOUND with assumed size array and non constant DIM

LBOUND with a non constant DIM argument use the runtime to allow runtime
verification of DIM <= RANK. The interface uses a descriptor.

[flang] Fix LBOUND with assumed size array and non constant DIM

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 <[email protected]>

show more ...


# 124338dd 23-Jun-2022 Val Donaldson <[email protected]>

[flang] Increase support for intrinsic module procedures

* Make Semantics test doconcurrent01.f90 an expected failure pending a fix
for a problem in recognizing a PURE prefix specifier for a specifi

[flang] Increase support for intrinsic module procedures

* 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 <[email protected]>

show more ...


Revision tags: llvmorg-14.0.6
# 70ade047 13-Jun-2022 vdonaldson <[email protected]>

[flang] system_clock intrinsic calls with dynamically optional arguments

system_clock intrinsic calls with dynamically optional arguments

Modify intrinsic system_clock calls to allow for an argumen

[flang] system_clock intrinsic calls with dynamically optional arguments

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 <[email protected]>

show more ...


Revision tags: llvmorg-14.0.5
# 5b66cc10 10-Jun-2022 Valentin Clement <[email protected]>

[flang][NFC] Move Todo.h from Lower to Optimizer

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 e

[flang][NFC] Move Todo.h from Lower to Optimizer

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 <[email protected]>

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D127292

show more ...


Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2
# fca52e82 25-Apr-2022 Jean Perier <[email protected]>

[flang] fix LBOUND lowering with KIND and no DIM arguments

The lowering code was mistakenly assuming that the second argument
in the signature provided by semantics is the DIM argument. This
caused

[flang] fix LBOUND lowering with KIND and no DIM arguments

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

show more ...


# 6243b90e 24-Apr-2022 Valentin Clement (バレンタイン クレメン) <[email protected]>

[flang] Do not create arith.extui with same from/to type

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/t

[flang] Do not create arith.extui with same from/to type

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

show more ...


# 58ceae95 18-Apr-2022 River Riddle <[email protected]>

[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespace

FuncOp has been moved to the `func` namespace for a little over a month, the
using directive can be dropped now.


Revision tags: llvmorg-14.0.1
# 189cb7df 11-Apr-2022 jeanPerier <[email protected]>

[flang] Lower optionals in GET_COMMAND_ARGUMENT and GET_ENVIRONMENT_VARIABLE

Handle dynamic optional argument in GET_COMMAND_ARGUMENT and GET_ENVIRONMENT_VARIABLE
(previously compiled but caused se

[flang] Lower optionals in GET_COMMAND_ARGUMENT and GET_ENVIRONMENT_VARIABLE

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

show more ...


# 4535bb9b 08-Apr-2022 Jean Perier <[email protected]>

[flang] Handle dynamically optional argument in EXIT

The actual argument passed to STATUS may be a dummy OPTIONAL or a
disassociated POINTER/unallocated ALLOCATABLE.

Differential Revision: https://

[flang] Handle dynamically optional argument in EXIT

The actual argument passed to STATUS may be a dummy OPTIONAL or a
disassociated POINTER/unallocated ALLOCATABLE.

Differential Revision: https://reviews.llvm.org/D123380

show more ...


12345