In some cases, the base type is already a fir.box type. This patch updates
the code to set the result box type to fir.box<T>, where T is the type
of the allocated temp.
This was reported in https://github.com/llvm/llvm-project/issues/59342
Reviewed By: jeanPerier, tblah
Differential Revision: https://reviews.llvm.org/D139401
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
SELECT TYPE lower and conversion was not handling
`character` type guard. This add support for it.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139106
Update the call conversion pattern to support fir.dispatch
operation as well. The first operand of fir.dispatch op is always the
polymoprhic object. The pass_arg_pos attribute needs to be shifted when
the result is added as argument.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D138799
Convert fir.select_type operation to an if-then-else ladder.
The type guards are sorted before the conversion so it follows the
execution of SELECT TYPE construct as mentioned in 11.1.11.2 point 4
of the Fortran standard.
Depends on D138279
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D138280
In general, the meaning of fastmath flags on a call during inlining
is that the call's operation flags must be ignored. For user functions
that means that the fastmath flags used for the function definition
override any call site's fastmath flags. For intrinsic functions
we can use the call site's fastmath flags, but we have to make sure
that the call sites with different flags produce/use different
simplified versions of the same intrinsic function.
Differential Revision: https://reviews.llvm.org/D138048
RewriteLoop.cpp is containing more than just loop conversion. It will
soon contains the fir.select_type conversion as well. This patch
renames the file so it is in line with the pass name.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D137773
Not all derived type can be taken as abstract result. The CPTR type
should be treated as return by value so to interoperable with C
functions. Fix the function result rewrite for CPTR type, but it
should be generalized for all derived types. The ABI of
interoperability with C for derived type is architecture dependent,
which should be supported later.
Reviewed By: PeteSteinfeld, jeanPerier
Differential Revision: https://reviews.llvm.org/D137548
This patch adds a cpowi function to the flang runtime, and switches
to using that function instead of pgmath for complex number to
integer power operations.
Differential Revision: https://reviews.llvm.org/D134889
This flips all of the remaining dialects to prefixed except for linalg, which
will be done in a followup.
Differential Revision: https://reviews.llvm.org/D134995
Create simplified functions for each rank with "x<rank>" suffix
that implement multidimensional reductions. To enable this I had to fix
an issue with taking incorrect box shape in cases of sliced embox/rebox.
Differential Revision: https://reviews.llvm.org/D133820
Use the RTNMAE macro (via stringify macros) to generate the name
strings for runtime functions, instead of using strings.
The sequence of macros generate exactly the same string as the
ones used previously, but this will support future changes in
runtime function names.
No functional change.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D132652
This removes a bunch of duplicated code, by adding an intermediate
function simplifyReduction that takes a std::function argument
for the actual replacement of the code.
No functional change intended.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D132588
The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure.
Reviewed By: mehdi_amini, rriddle
Differential Review: https://reviews.llvm.org/D132838
The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure.
Reviewed By: mehdi_amini, rriddle
Differential Review: https://reviews.llvm.org/D132838
This pass allows to convert operations
which use functions with abstract results to ones that do not.
Depends on D130087
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D130088
The SUM function does appear to be safe to use, so remove the
experimental flag for the SUM operation.
Reviewed By: vzakhari, awarzynski
Differential Revision: https://reviews.llvm.org/D132567
Add simplifcation pass for MAXVAL intrinsic function
This refactors some of the code to allow variation on the
initialization value and operation performed within the loop,
reusing the majority of code for both SUM and MAXVAL.
Adding tests for the test-cases that produce different output
than the SUM function.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D132234
Under some conditions, the defining op may be NULL, so
accept that rahter than try to use it and crash!
Adds test to prevent regression
Fixes github issue #57201
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D132238
The current code may not always work correctly, e.g.:
https://github.com/llvm/llvm-project/issues/57201
I added 'enable-experimental' pass option so that SUM simplification
may be enabled in LIT tests, but it is not enabled when the pass
is added to the passes pipeline.
Differential Revision: https://reviews.llvm.org/D131640
Fix one encountered (issue #57072) and two potential scenarios where the
code would ask for an operand that isn't there.
Add test for the encountered case.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D131671
Fortran runtime supports mixed types by casting the loaded values
to the result type, so DOT_PRODUCT simplification has to do the same.
Differential Revision: https://reviews.llvm.org/D131726
I would like to add DOT_PRODUCT support in this pass, so this restructuring
is the first step to allow some code reuse inside getOrCreateFunction().
Differential Revision: https://reviews.llvm.org/D131530
The newly added AlgebraicSimplification pass is triggering the
greedy pattern rewriter. Since we define a specific config in the
flang pipeline, this patch adds the ability to pass the config
to the pass directly.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D131474
Find calls to FortranASum{Real8,Integer4}, check for dim and mask
arguments being absent - then produce an inlineable simple
version of the sum function.
(No longer a prototype, please review for push to llvm/main - not sure how to make Phabricator update the review with actual commit message)
Reviewed By: peixin, awarzynski
Differential Revision: https://reviews.llvm.org/D125407
This change decouples common functionality for convering abstract
results, so it can be reused later.
Depends on D129485
Reviewed By: clementval, jeanPerier
Differential Revision: https://reviews.llvm.org/D129778
This patch replaces x.getValue() with *x if the reference is obviously
protected by a presence check. Otherwise, it replaces x.getValue()
with x.value().
Flang C++ Style Guide tells us to use *X when the reference is
protected by a presense test. However, (*X).foo() is a little harder
to read, especially when X is a complicated expression.
This patch slightly deviates from the guide (but retains the spirit)
by using X->foo() instead.
Differential Revision: https://reviews.llvm.org/D130413
Try 2 to merge 4fbd1d6c87.
Flang algebraic simplification pass will run algebraic simplification
rewrite patterns for Math/Complex/etc. dialects. It is enabled
under opt-for-speed optimization levels (i.e. for O1/O2/O3; Os/Oz will not
enable it).
With this change the FIR/MLIR optimization pipeline becomes affected
by the -O* optimization level switches. Until now these switches
only affected the middle-end and back-end.
Differential Revision: https://reviews.llvm.org/D130035
Flang algebraic simplification pass will run algebraic simplification
rewrite patterns for Math/Complex/etc. dialects. It is enabled
under opt-for-speed optimization levels (i.e. for O1/O2/O3; Os/Oz will not
enable it).
With this change the FIR/MLIR optimization pipeline becomes affected
by the -O* optimization level switches. Until now these switches
only affected the middle-end and back-end.
Differential Revision: https://reviews.llvm.org/D130035
`AbstractResultOptions` is obsolete structure because `newArg` is used
only in `ReturnOpConversion`.
This change removes this struct, making dependencies of conversions more
straight-forward.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D129485
FirOpBuilder takes a fir::KindMapping reference. When the getKindMapping()
call is made inside the ctor call, the lifetime of this reference may
be as short as the ctor call (at least with when building flang in
release mode with clang 8). This can cause segfaults when later using
the FirOpBuilder.
Ensure the kindMap passed to the FirOpBuilder ctor is the same as the
FirOpBuilder.
Differential Revision: https://reviews.llvm.org/D129494
Flang C++ Style Guide tells us to avoid .has_value() in the predicate
expressions of control flow statements. I am treating ternary
expressions as control flow statements for the purpose of this patch.
Differential Revision: https://reviews.llvm.org/D128622
Array-value-copy fails to generate a temporary array for case like this:
subroutine bug(b)
real, allocatable :: b(:)
b = b(2:1:-1)
end subroutine
Since LHS may need to be reallocated, lowering produces the following FIR:
%rhs_load = fir.array_load %b %slice
%lhs_mem = fir.if %b_is_allocated_with_right_shape {
fir.result %b
} else {
%new_storage = fir.allocmem %rhs_shape
fir.result %new_storage
}
%lhs = fir.array_load %lhs_mem
%loop = fir.do_loop {
....
}
fir.array_merge_store %lhs, %loop to %lhs_mem
// deallocate old storage if reallocation occured,
// and update b descriptor if needed.
Since %b in array_load and %lhs_mem in array_merge_store are not the same SSA
values, array-value-copy does not detect the conflict and does not produce
a temporary array. This causes incorrect result in runtime.
The suggested change in lowering is to generate this:
%rhs_load = fir.array_load %b %slice
%lhs_mem = fir.if %b_is_allocated_with_right_shape {
%lhs = fir.array_load %b
%loop = fir.do_loop {
....
}
fir.array_merge_store %lhs, %loop to %b
fir.result %b
} else {
%new_storage = fir.allocmem %rhs_shape
%lhs = fir.array_load %new_storage
%loop = fir.do_loop {
....
}
fir.array_merge_store %lhs, %loop to %new_storage
fir.result %new_storage
}
// deallocate old storage if reallocation occured,
// and update b descriptor if needed.
Note that there are actually 3 branches in FIR, so the assignment loops
are currently produced in three copies, which is a code-size issue.
It is possible to generate just two branches with two copies of the loops,
but it is not addressed in this change-set.
Differential Revision: https://reviews.llvm.org/D129314
- Add verifiers that determine if an Op requires type parameters or
not and checks that the correct number of parameters is specified.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D128828
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
