#
460fc79a |
| 29-Apr-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fold intrinsic inquiry functions SAME_TYPE_AS() and EXTENDS_TYPE_OF()
When the result can be known at compilation time, fold it. Success depends on whether the operands are polymorphic. When
[flang] Fold intrinsic inquiry functions SAME_TYPE_AS() and EXTENDS_TYPE_OF()
When the result can be known at compilation time, fold it. Success depends on whether the operands are polymorphic. When neither one is polymorphic, the result is known and can be either .TRUE. or .FALSE.; when either one is polymorphic, a .FALSE. result still can be discerned.
Differential Revision: https://reviews.llvm.org/D125062
show more ...
|
#
cd03e96f |
| 23-Mar-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Add & use a better visit() (take 2)
Adds flang/include/flang/Common/log2-visit.h, which defines a Fortran::common::visit() template function that is a drop-in replacement for std::visit().
[flang] Add & use a better visit() (take 2)
Adds flang/include/flang/Common/log2-visit.h, which defines a Fortran::common::visit() template function that is a drop-in replacement for std::visit(). Modifies most use sites in the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution time, which forces implementations to build dispatch tables. This new common::visit() is O(log2 N) in the number of alternatives in a variant<>, but that N tends to be small and so this change produces a fairly significant improvement in compiler build memory requirements, a 5-10% improvement in compiler build time, and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit() to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments are referred to std::visit(), pending further work.
This change is enabled only for GCC builds with GCC >= 9; an earlier attempt (D122441) ran into bugs in some versions of clang and was reverted rather than simply disabled; and it is not well tested with MSVC. In non-GCC and older GCC builds, common::visit() is simply an alias for std::visit().
show more ...
|
#
4ca111d4 |
| 28-Mar-2022 |
Andrzej Warzynski <andrzej.warzynski@arm.com> |
Revert "[flang] Add & use a better visit()"
This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has caused multiple build failures: * https://lab.llvm.org/buildbot/#/builders/177/build
Revert "[flang] Add & use a better visit()"
This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has caused multiple build failures: * https://lab.llvm.org/buildbot/#/builders/177/builds/4346 * https://lab.llvm.org/buildbot/#/builders/180/builds/3803 * https://lab.llvm.org/buildbot/#/builders/175/builds/10419 * https://lab.llvm.org/buildbot/#/builders/191/builds/4318 * https://lab.llvm.org/buildbot/#/builders/173/builds/4274 * https://lab.llvm.org/buildbot/#/builders/181/builds/4297
All these bots failed with a time-out: ``` command timed out: 1200 seconds without output running [b'ninja', b'-j', b'32'], attempting to kill ``` I'm guessing that that's due to template instantiations failing at some point (https://reviews.llvm.org/D122441 introduced a custom implementation of std::visit). Everything seems fine when either: * building on X86 with GCC or Clang (tested with GCC 9.3 and Clang 12) * building on AArch64 with GCC (tested with GCC 11)
show more ...
|
#
2ab9990c |
| 23-Mar-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Add & use a better visit()
Adds flang/include/flang/Common/visit.h, which defines a Fortran::common::visit() template function that is a drop-in replacement for std::visit(). Modifies most
[flang] Add & use a better visit()
Adds flang/include/flang/Common/visit.h, which defines a Fortran::common::visit() template function that is a drop-in replacement for std::visit(). Modifies most use sites in the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution time, which forces implementations to build dispatch tables. This new common::visit() is O(log2 N) in the number of alternatives in a variant<>, but that N tends to be small and so this change produces a fairly significant improvement in compiler build memory requirements, a 5-10% improvement in compiler build time, and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit() to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments are referred to std::visit(), pending further work.
Differential Revision: https://reviews.llvm.org/D122441
show more ...
|
#
d3f5ef24 |
| 21-Jan-2022 |
Yury Gribov <tetra2005@gmail.com> |
Add ieee_is_normal/ieee_is_negative to ieee_arithmetic module.
|
#
5c5bde1b |
| 30-Dec-2021 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fold SCALE()
Fold references to the intrinsic function SCALE().
(Also work around some MSVC headaches somehow exposed by this patch: disable a bogus MSVC warning that began to appear in unr
[flang] Fold SCALE()
Fold references to the intrinsic function SCALE().
(Also work around some MSVC headaches somehow exposed by this patch: disable a bogus MSVC warning that began to appear in unrelated source files, and avoid the otherwise-necessary use of the "template" keyword in a call to a template member function of a class template.)
Differential Revision: https://reviews.llvm.org/D117150
show more ...
|
#
2f80b73e |
| 13-Oct-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Fold BTEST
Implements constant folding for BTEST intrinsic function.
Differential Revision: https://reviews.llvm.org/D111849
|
#
6965a776 |
| 13-Oct-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Fold LGE/LGT/LLE/LLT intrinsic functions
Fold the legacy intrinsic functions LGE, LGT, LLE, & LLT by rewriting them into character relational expressions and then folding those. Also fix fo
[flang] Fold LGE/LGT/LLE/LLT intrinsic functions
Fold the legacy intrinsic functions LGE, LGT, LLE, & LLT by rewriting them into character relational expressions and then folding those. Also fix folding of comparisons of character values of distinct lengths: the shorter value must be padded with blanks. (This fix exposed some bad test cases, which are also fixed.)
Differential Revision: https://reviews.llvm.org/D111843
show more ...
|
#
82568675 |
| 28-Sep-2021 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fold FINDLOC()
Fold the transformational intrinsic function FINDLOC() for all combinations of optional arguments and data types.
Differential Revision: https://reviews.llvm.org/D110757
|
#
26aff847 |
| 10-Sep-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Fold COUNT()
Complete folding of the intrinsic reduction function COUNT() for all cases, including partial reductions with DIM= arguments.
Differential Revision: https://reviews.llvm.org/D1
[flang] Fold COUNT()
Complete folding of the intrinsic reduction function COUNT() for all cases, including partial reductions with DIM= arguments.
Differential Revision: https://reviews.llvm.org/D109911
show more ...
|
#
3fefebab |
| 24-Aug-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Fold EOSHIFT
Implement constant folding for the transformational intrinsic function EOSHIFT.
Differential Revision: https://reviews.llvm.org/D108941
|
#
0bbb2d00 |
| 07-Jul-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Fold CSHIFT
Implement folding of the transformational intrinsic function CSHIFT for all types.
Differential Revision: https://reviews.llvm.org/D108931
|
#
503c085e |
| 18-Jun-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Fold more reduction intrinsic function calls
Refactor the recently-implemented MAXVAL/MINVAL folding so that the parts that can be used to implement other reduction transformational intrinsi
[flang] Fold more reduction intrinsic function calls
Refactor the recently-implemented MAXVAL/MINVAL folding so that the parts that can be used to implement other reduction transformational intrinsic function folding are exposed.
Use them to implement folding of IALL, IANY, IPARITY, SUM. and PRODUCT. Replace the folding of ALL & ANY to use the new infrastructure and become able to handle DIM= arguments.
Differential Revision: https://reviews.llvm.org/D104562
show more ...
|
#
71d868cf |
| 15-Apr-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Define missing & needed IEEE_ARITHMETIC symbols
Define IEEE_IS_NAN, IEEE_IS_FINITE, & IEEE_REM.
Differential Revision: https://reviews.llvm.org/D100599
|
#
27899112 |
| 25-Mar-2021 |
Jean Perier <jperier@nvidia.com> |
[flang] fold LOGICAL intrinsic calls
Folding of LOGICAL intrinsic procedure was missing in the front-end causing crash when using it in parameter expressions. Simply fold LOGICAL calls to evaluate::
[flang] fold LOGICAL intrinsic calls
Folding of LOGICAL intrinsic procedure was missing in the front-end causing crash when using it in parameter expressions. Simply fold LOGICAL calls to evaluate::Convert<T>.
Differential Revision: https://reviews.llvm.org/D99346
show more ...
|
#
aa39ddd0 |
| 01-Feb-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Implement IEEE_SUPPORT_xxx inquiry functions
Implement IEEE_SUPPORT_DATATYPE() and other inquiry intrinisic functions from the intrinsic module IEEE_ARITHMETIC, folding all of their results
[flang] Implement IEEE_SUPPORT_xxx inquiry functions
Implement IEEE_SUPPORT_DATATYPE() and other inquiry intrinisic functions from the intrinsic module IEEE_ARITHMETIC, folding all of their results to .TRUE.
Differential Revision: https://reviews.llvm.org/D95830
show more ...
|
#
641ede93 |
| 07-Dec-2020 |
peter klausler <pklausler@nvidia.com> |
[flang] Improve initializer semantics, esp. for component default values
This patch plugs many holes in static initializer semantics, improves error messages for default initial values and other com
[flang] Improve initializer semantics, esp. for component default values
This patch plugs many holes in static initializer semantics, improves error messages for default initial values and other component properties in parameterized derived type instantiations, and cleans up several small issues noticed during development. We now do proper scalar expansion, folding, and type, rank, and shape conformance checking for component default initializers in derived types and PDT instantiations. The initial values of named constants are now guaranteed to have been folded when installed in the symbol table, and are no longer folded or scalar-expanded at each use in expression folding. Semantics documentation was extended with information about the various kinds of initializations in Fortran and when each of them are processed in the compiler.
Some necessary concomitant changes have bulked this patch out a bit: * contextual messages attachments, which are now produced for parameterized derived type instantiations so that the user can figure out which instance caused a problem with a component, have been added as part of ContextualMessages, and their implementation was debugged * several APIs in evaluate::characteristics was changed so that a FoldingContext is passed as an argument rather than just its intrinsic procedure table; this affected client call sites in many files * new tools in Evaluate/check-expression.cpp to determine when an Expr actually is a single constant value and to validate a non-pointer variable initializer or object component default value * shape conformance checking has additional arguments that control whether scalar expansion is allowed * several now-unused functions and data members noticed and removed * several crashes and bogus errors exposed by testing this new code were fixed * a -fdebug-stack-trace option to enable LLVM's stack tracing on a crash, which might be useful in the future
TL;DR: Initialization processing does more and takes place at the right times for all of the various kinds of things that can be initialized.
Differential Review: https://reviews.llvm.org/D92783
show more ...
|
#
df62afd5 |
| 13-Nov-2020 |
peter klausler <pklausler@nvidia.com> |
[flang] Unsplit COMPLEX operations
COMPLEX negation, addition, subtraction, conversions of kind, and equality/inequality were represented as component-wise REAL operations. It turns out to be easie
[flang] Unsplit COMPLEX operations
COMPLEX negation, addition, subtraction, conversions of kind, and equality/inequality were represented as component-wise REAL operations. It turns out to be easier for lowering if we do not split and recombine these COMPLEX operations, and it avoids a potential problem with COMPLEX valued function calls in these contexts. So add this suite of operations to the typed expression representation in place of the component-wise transformations, and support them in folding.
Differential revision: https://reviews.llvm.org/D91443
show more ...
|
#
29fa4518 |
| 10-Nov-2020 |
peter klausler <pklausler@nvidia.com> |
[flang] Add isnan() extension intrinsic function, with folding
It's nonstandard, but commonly implemented.
Differential revision: https://reviews.llvm.org/D91213
|
#
c7574188 |
| 25-Sep-2020 |
Peter Steinfeld <psteinfeld@nvidia.com> |
[flang] Failed call to CHECK() for call to ASSOCIATED(NULL())
Calling "ASSOCATED(NULL()) was causing an internal check of the compiler to fail.
I fixed this by changing the entry for "ASSOCIATED" i
[flang] Failed call to CHECK() for call to ASSOCIATED(NULL())
Calling "ASSOCATED(NULL()) was causing an internal check of the compiler to fail.
I fixed this by changing the entry for "ASSOCIATED" in the intrinsics table to accept "AnyPointer" which contains a new "KindCode" of "pointerType". I also changed the function "FromActual()" to return a typeless intrinsic when called on a pointer, which duplicates its behavior for BOZ literals. This required changing the analysis of procedure arguments. While testing processing for procedure arguments, I found another bad call to `CHECK()` which I fixed.
I made several other changes: -- I implemented constant folding for ASSOCIATED(). -- I fixed handling of NULL() in relational operations. -- I implemented semantic analysis for ASSOCIATED(). -- I noticed that the semantics for ASSOCIATED() are similar to those for pointer assignment. So I extracted the code that pointer assignment uses for procedure pointer compatibility to a place where it could be used by the semantic analysis for ASSOCIATED(). -- I couldn't figure out how to make the general semantic analysis for procedure arguments work with ASSOCIATED()'s second argument, which can be either a pointer or a target. So I stopped using normal semantic analysis for arguments for ASSOCIATED(). -- I added tests for all of this.
Differential Revision: https://reviews.llvm.org/D88313
show more ...
|
#
1f879005 |
| 29-Mar-2020 |
Tim Keith <tkeith@nvidia.com> |
[flang] Reformat with latest clang-format and .clang-format
Original-commit: flang-compiler/f18@9fe84f45d7fd685051004678d6b5775dcc4c6f8f Reviewed-on: https://github.com/flang-compiler/f18/pull/1094
|
#
64ab3302 |
| 25-Feb-2020 |
CarolineConcatto <51754594+CarolineConcatto@users.noreply.github.com> |
[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)
This patch renames the modules in f18 to use a capital letter in the
module name
Signed-off-b
[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)
This patch renames the modules in f18 to use a capital letter in the
module name
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Original-commit: flang-compiler/f18@d2eb7a1c443d1539ef12b6f027074a0eb15b1ea0 Reviewed-on: https://github.com/flang-compiler/f18/pull/980
show more ...
|