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