Commit Graph

73 Commits

Author SHA1 Message Date
Slava Zakharin 56eda98f0c [flang] Handle mixed types in DOT_PRODUCT simplification.
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
2022-08-15 09:03:38 -07:00
Slava Zakharin 1d5e7a498f [flang] Support DOT_PRODUCT in late inlining.
This change inlines DOT_PRODUCT calls for real and integer types.

Differential Revision: https://reviews.llvm.org/D131538
2022-08-10 16:30:35 -07:00
Slava Zakharin 80dcc907a8 [NFC] Restructured SimplifyIntrinsicsPass::getOrCreateFunction.
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
2022-08-10 09:40:57 -07:00
Valentin Clement 4dece4007c
[flang] Pass the pipeline config to the pass
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
2022-08-09 16:05:34 +02:00
Mats Petersson 6e193b5cbb Prepare for inlining of SUM intrinsic
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
2022-08-04 20:56:19 +01:00
Daniil Dudkin cb33e4ab14 [flang] Generalize `AbstractResultOpt` pass
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
2022-07-27 11:55:17 +03:00
Kazu Hirata 3356d72a5f [flang] Use value or * instead of getValue (NFC)
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().
2022-07-25 23:01:01 -07:00
Kazu Hirata fac0fb4d96 [flang] Use X->foo() instead of X.getValue().foo() (NFC)
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
2022-07-25 00:55:06 -07:00
Slava Zakharin 9c0acc42e8 [flang] Run algebraic simplification optimization pass.
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
2022-07-21 11:43:39 -07:00
Slava Zakharin 7434375666 Revert "[flang] Run algebraic simplification optimization pass."
This reverts commit 4fbd1d6c87.
2022-07-20 16:56:28 -07:00
Slava Zakharin 4fbd1d6c87 [flang] Run algebraic simplification optimization pass.
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
2022-07-20 16:33:52 -07:00
Daniil Dudkin ea1cdb58cc [flang][NFC] Drop `AbstractResultOptions` structure
`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
2022-07-19 17:23:09 +03:00
Kazu Hirata 8b3ed1fa98 Remove redundant return statements (NFC)
Identified with readability-redundant-control-flow.
2022-07-17 15:37:46 -07:00
Kazu Hirata 009ab1728d [flang] Use *X instead of X.getValue() (NFC)
Per Flang C++ Style Guide, this patch replaces X.getValue() with *X
where *X is protected by a presence test.
2022-07-16 00:24:02 -07:00
Jean Perier 906784a399 [flang] move getKindMapping() calls out of FIROpBuilder ctor calls
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
2022-07-12 09:22:59 +02:00
Kazu Hirata c82fb16f58 [flang] Use has_value instead of hasValue (NFC)
This patch replaces hasValue with has_value in an effort to deprecate
Optional<X>::hasValue.

Differential Revision: https://reviews.llvm.org/D129458
2022-07-11 20:41:12 -07:00
Kazu Hirata 86b8c1d9c4 [flang] Don't use Optional::hasValue (NFC)
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
2022-07-10 15:01:06 -07:00
Slava Zakharin 73026a4fbf [flang] Changed lowering for allocatable assignment to make array-value-copy correct.
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
2022-07-08 09:41:34 -07:00
Valentin Clement 649439e7ae
[flang] Fix lowering issue with character temp
- 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>
2022-06-29 20:06:54 +02:00
Kazu Hirata 3b7c3a654c Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3.
2022-06-25 11:56:50 -07:00
Kazu Hirata aa8feeefd3 Don't use Optional::hasValue (NFC) 2022-06-25 11:55:57 -07:00
Kazu Hirata ed8fceaa09 Don't use Optional::getValue (NFC) 2022-06-20 23:35:53 -07:00
Alex Zinenko 8b68da2c7d [mlir] move SCF headers to SCF/{IR,Transforms} respectively
This aligns the SCF dialect file layout with the majority of the dialects.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D128049
2022-06-20 10:18:01 +02:00
Jacques Pienaar 8df54a6a03 [mlir] Update accessors to prefixed form (NFC)
Follow up from flipping dialects to both, flip accessor used to prefixed
variant ahead to flipping from _Both to _Prefixed. This just flips to
the accessors introduced in the preceding change which are just prefixed
forms of the existing accessor changed from.

Mechanical change using helper script
https://github.com/jpienaar/llvm-project/blob/main/clang-tools-extra/clang-tidy/misc/AddGetterCheck.cpp and clang-format.
2022-06-18 17:53:22 -07:00
Valentin Clement 3260d42398
[flang] Avoid losing type parameter information
This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-06-14 15:57:56 +02:00
Jean Perier 9de831aa2c
Add lowering TODO for bindings returning derived types or arrays
Codegen does not support fir.addressof of functions returning derived
types, arrays are descriptors inside GlobalOp region.

This is because the  abstract-result-opt is required to rewrite such
functions (a hidden argument must be added), but this pass is meant to
run in GlobalOp currently.

Such fir.address_of may be created when lowering procedure pointers
initial value (TODO), or when creating derived type descriptors for
types with bindings.

Add a TODO in lowering until abstract-result-opt is modified to run
on GlobalOp too.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D127722
2022-06-14 10:48:44 +02:00
Mogball e16d13322b [mlir] (NFC) Clean up bazel and CMake target names
All dialect targets in bazel have been named *Dialect and all dialect
targets in CMake have been named MLIR*Dialect.
2022-06-13 16:24:15 +00:00
Valentin Clement 5b66cc1000
[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 <eschweitz@nvidia.com>

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D127292
2022-06-10 08:51:05 +02:00
River Riddle 58ceae9561 [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.
2022-04-18 12:01:55 -07:00
River Riddle 5e50dd048e [mlir] Rework the implementation of TypeID
This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implicit" fallback path to use the name of the type, instead of using
a static template variable (which breaks shared libraries). The major downside to this
is that it adds some additional initialization costs for the implicit path. Given the
use of type names for uniqueness in the fallback, we also no longer allow types
defined in anonymous namespaces to have an implicit TypeID. To simplify defining
an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro
was added to allow for explicitly defining a TypeID directly on an internal class.

To help identify when types are using the fallback, `-debug-only=typeid` can be
used to log which types are using implicit ids.

This change generally only requires changes to the test passes, which are all defined
in anonymous namespaces, and thus can't use the fallback any longer.

Differential Revision: https://reviews.llvm.org/D122775
2022-04-04 13:52:26 -07:00
Valentin Clement fe252f8ed6
[flang] Lower boxed procedure
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>
2022-03-22 15:41:11 +01:00
Jean Perier 3ed899cc74 [flang] handle allocatable components when creating array temps
When creating an array temporary in the array copy pass, care must be
taken with allocatable components. The element components needs to be
given a clean unallocated status before being used in the assignments.
This is because assignment of allocatable components makes deep copy,
and may cause deallocation of the previous value if it was allocated.
Hence the previous allocation status cannot be let undefined.

On top of that, when cleaning-up the temp, all allocatable components
that may have been allocated must be deallocated.

This patch implements this by centralizing the code making and cleaning
array temps in ArrayValueCopy.cpp, and by calling Initialize and Destroy
runtime entry points when they are allocatable components.

Differential Revision: https://reviews.llvm.org/D121892
2022-03-17 10:56:20 +01:00
River Riddle 4a3460a791 [mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"
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
2022-03-16 17:07:04 -07:00
Valentin Clement 9aeb7f035b
[flang] Lower IO input with vector subscripts
This patch adds lowering for IO input with vector subscripts.
It defines a VectorSubscriptBox class that allow representing and working
with a lowered Designator containing vector subscripts while ensuring
all the subscripts expression are only lowered once.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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

Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-03-16 17:13:23 +01:00
Eric Schweitz c2e7e75954 Write a pass to annotate constant operands on FIR ops. This works
around the feature in MLIR's canonicalizer, which considers the semantics
of constants differently based on how they are packaged and not their
values and use.  Add test.

Reviewed By: clementval

Differential Revision: https://reviews.llvm.org/D121625
2022-03-14 11:14:44 -07:00
Valentin Clement beeb86bd65
[flang] Update ArrayValueCopy to support array_amend and array_access
This patch update the array value copy pass to support fir-array_amend
and fir.array_access.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld, schweitz

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

Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2022-03-09 19:33:24 +01:00
Andrzej Warzynski 092601d4ba [flang] Remove 'using namespace mlir;` from header files
Currently, CGOps.h and FIROps.h contain `using namespace mlir;`. Every
file that includes one of these header files (directly and transitively)
will have the MLIR namespace enabled. With name-clashes within
sub-projects (LLVM and MLIR, MLIR and Flang), this is not desired. Also,
it is not possible to "un-use" a namespace once it is "used". Instead,
we should try to limit `using namespace` to implementation files (i.e.
*.cpp).

This patch removes `using namespace mlir;` from header files and adjusts
other files accordingly. In header and TableGen files, extra namespace
qualifier is added when referring to symbols defined in MLIR. Similar
approach is adopted in source files that didn't require many changes. In
files that would require a lot of changes, `using namespace mlir;` is
added instead.

Differential Revision: https://reviews.llvm.org/D120897
2022-03-09 10:19:51 +00:00
River Riddle f8d5c73c82 [mlir][NFC] Update the Builtin dialect to use "Both" accessors
Differential Revision: https://reviews.llvm.org/D121189
2022-03-08 12:25:32 -08:00
River Riddle 1f971e23f0 [mlir] Trim a huge number of unnecessary dependencies on the Func dialect
The Func has a large number of legacy dependencies carried over from the old
Standard dialect, which was pervasive and contained a large number of varied
operations. With the split of the standard dialect and its demise, a lot of lingering
dead dependencies have survived to the Func dialect. This commit removes a
large majority of then, greatly reducing the dependence surface area of the
Func dialect.
2022-03-01 12:10:04 -08:00
River Riddle 23aa5a7446 [mlir] Rename the Standard dialect to the Func dialect
The last remaining operations in the standard dialect all revolve around
FuncOp/function related constructs. This patch simply handles the initial
renaming (which by itself is already huge), but there are a large number
of cleanups unlocked/necessary afterwards:

* Removing a bunch of unnecessary dependencies on Func
* Cleaning up the From/ToStandard conversion passes
* Preparing for the move of FuncOp to the Func dialect

See the discussion at https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061

Differential Revision: https://reviews.llvm.org/D120624
2022-03-01 12:10:04 -08:00
Shraiysh Vaishay 149ad3d554 [flang][mlir][NFC] Replace uses of raw accessors with prefixed accessors
`kEmitAccessorPrefix_Raw ` is being removed, and so updating the
accessors to `kEmitAccessorPrefix_Prefixed`.

Reviewed By: clementval

Differential Revision: https://reviews.llvm.org/D119812
2022-02-15 21:07:46 +05:30
Uday Bondhugula 7d7ebf3cf0 Fix flang build breakage - trim dependency to AffineUtils
There wasn't a need for FIRTransforms to depend on AffineToStandard
conversoin for just an affine utility. The utility was moved to
AffineUtils recently. Fix flang build breakage.

Differential Revision: https://reviews.llvm.org/D119408
2022-02-10 11:33:55 +05:30
River Riddle ace01605e0 [mlir] Split out a new ControlFlow dialect from Standard
This dialect is intended to model lower level/branch based control-flow constructs. The initial set
of operations are: AssertOp, BranchOp, CondBranchOp, SwitchOp; all split out from the current
standard dialect.

See https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061

Differential Revision: https://reviews.llvm.org/D118966
2022-02-06 14:51:16 -08:00
River Riddle dec8af701f [mlir] Move SelectOp from Standard to Arithmetic
This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.

Differential Revision: https://reviews.llvm.org/D118648
2022-02-02 14:45:12 -08:00
River Riddle 9f85c198db [mlir] Finish replacing OwningRewritePatternList with RewritePatternSet
OwningRewritePatternList has been deprecated for ~10 months now, we can remove
the leftover using directives at this point.

Differential Revision: https://reviews.llvm.org/D118287
2022-01-26 23:11:02 -08:00
Valentin Clement 4d53f88d1a
[flang] Add MemoryAllocation pass to the pipeline
Add the MemoryAllocation pass into the pipeline. Add
the possibilty to pass the options directly within the tool (tco).

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D117886
2022-01-24 16:32:39 +01:00
Valentin Clement ccaaeca910
[flang][NFC] Move current inliner files in Dialect directory
This patch just move the files from the Transforms directory to
the Dialect directory.

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D117661
2022-01-20 13:34:44 +01:00
River Riddle e084679f96 [mlir] Make locations required when adding/creating block arguments
BlockArguments gained the ability to have locations attached a while ago, but they
have always been optional. This goes against the core tenant of MLIR where location
information is a requirement, so this commit updates the API to require locations.

Fixes #53279

Differential Revision: https://reviews.llvm.org/D117633
2022-01-19 17:35:35 -08:00
River Riddle 196c4279c0 [flang] Convert uses of FunctionPass to OperationPass<FuncOp>
FunctionPass has been deprecated and is in the process of being removed.
2022-01-18 20:46:44 -08:00
Valentin Clement 3ab67c3d62
[fir] Move Factory.h to flang/Optimizer/Builder
Move the Factory.h header file to flang/Optimizer/Builder.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: kiranchandramohan

Differential Revision: https://reviews.llvm.org/D115801
2021-12-16 16:08:34 +01:00