Flang supports lowering collapse clause to MLIR for worksharing loops
and simd loops. Simd collapse clause is represented in MLIR code as a
simd-loop having a list of indices, bounds and steps where the size of the list
is equal to the collapse value.
Support for simd collapse clause was added by several patches:
https://reviews.llvm.org/D118065 -> basic support for simd-loop in MLIR.
Loop collapsing is done in the same way as
for worksharing loops:
https://reviews.llvm.org/D105706https://reviews.llvm.org/D125282 -> support for lowering simd clause from
Fortran into MLIR
https://reviews.llvm.org/D125302 -> lowering collapse clause from Fortran to
MLIR. Lowering collapse clause is done
before simd-specific function is called.
https://reviews.llvm.org/D128338 -> modified the MLIR representation of
collapse clause. Removed collapse keyword
in OpenMP MLIR dialect. Use loop list to
represent collapse clause. This loop list
is created by changes from patch:
https://reviews.llvm.org/D125302 and it is
passed to function responsible for lowering
of simd directive which was implemented in
patch: https://reviews.llvm.org/D125282
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D132023
Signed-off-by: Dominik Adamski <dominik.adamski@amd.com>
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
When testing LLVM 15.0.0 rc1 on Solaris, I found that 50+ flang tests
`FAIL`ed with
error:
/vol/llvm/src/llvm-project/local/flang/lib/Optimizer/CodeGen/Target.cpp:310:
not yet implemented: target not implemented
This patch fixes that for Solaris/x86, where the fix is trivial (just
handling it like the other x86 OSes).
Tested on `amd64-pc-solaris2.11`; only a single failure remains now.
Differential Revision: https://reviews.llvm.org/D131054
This document aims to give insights at the representation of polymorphic
entities in FIR and how polymorphic related constructs and features are lowered
to FIR.
Reviewed By: klausler, razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131515
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
This patch adds tests for the handling of array sections for
arrays with the ALLOCATABLE or POINTER attribute.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131885
Make sure that FortranDecimal, FortranRuntime and Fortran_main are
installed/packaged even when LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.
They are used by flang to link executables, so they should be provided
even with minimal installs.
Differential Revision: https://reviews.llvm.org/D131670
This patch lowers correctly operands with array section
and derived-type component.
Depends on D131764
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131765
This reland includes changes to the Python bindings.
Switch variadic operand and result segment size attributes to use the
dense i32 array. Dense integer arrays were introduced primarily to
represent index lists. They are a better fit for segment sizes than
dense elements attrs.
Depends on D131801
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D131803
The SemanticsContext is needed to analyze expression later in the
lowering for directive languages. This patch allows to keep a reference of
the SemanticsContext in the LoweringBridge.
Building block for D131765
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131764
This patch adds lowering support for default clause.
1. During symbol resolution in semantics, should the enclosing context
have a default data sharing clause defined and a `parser::Name` is not
attached to an explicit data sharing clause, the
`semantics::Symbol::Flag::OmpPrivate` flag (in case of
default(private)) and `semantics::Symbol::Flag::OmpFirstprivate` flag
(in case of default(firstprivate)) is added to the symbol.
2. During lowering, all symbols having either
`semantics::Symbol::Flag::OmpPrivate` or
`semantics::Symbol::Flag::OmpFirstprivate` flag are collected and
privatised appropriately.
Co-authored-by: Peixin Qiao <qiaopeixin@huawei.com>
Reviewed by: peixin
Differential Revision: https://reviews.llvm.org/D123930
This patch adds lowering support for default clause.
1. During symbol resolution in semantics, should the enclosing context have
a default data sharing clause defined and a `parser::Name` is not attached
to an explicit data sharing clause, the
`semantics::Symbol::Flag::OmpPrivate` flag (in case of default(private))
and `semantics::Symbol::Flag::OmpFirstprivate` flag (in case of
default(firstprivate)) is added to the symbol.
2. During lowering, all symbols having either
`semantics::Symbol::Flag::OmpPrivate` or
`semantics::Symbol::Flag::OmpFirstprivate` flag are collected and
privatised appropriately.
Co-authored-by: Peixin Qiao <qiaopeixin@huawei.com>
Reviewed by: peixin
Differential Revision: https://reviews.llvm.org/D123930
Switch variadic operand and result segment size attributes to use the
dense i32 array. Dense integer arrays were introduced primarily to
represent index lists. They are a better fit for segment sizes than
dense elements attrs.
Depends on D131738
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D131702
Location information was not correctly propagated when creating OpenACC
operations. This patch propagate the correct location information from
the parse tree nodes to OpenACC MLIR operations.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131659
This patch "modernizes" the LLVM `insertvalue` and `extractvalue`
operations to use DenseI64ArrayAttr, since they only require an array of
indices and previously there was confusion about whether to use i32 or
i64 arrays, and to use assembly format.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D131537
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
Flang was not able to convert simd directive which contains nested
Fortran loops. The nested Fortran loops inside SIMD directive
are modelled as FIR loops and they need to be translated into LLVM
MLIR dialect.
Differential Revision: https://reviews.llvm.org/D131402
Reviewed by: peixin
Signed-off-by: Dominik Adamski <dominik.adamski@amd.com>
Adds support for reduction of multiplcation
by extending OpenMP.cpp::genOpenMPReduction()
and altering the identity constant emitted in
OpenMP.cpp::createReductionDelc()
This patch builds D130077 and as such,
only supports reductions for interger types in
worksharping loops.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D130767
Procedure bindings with explicit interfaces don't work when the
interface is shadowed by a generic interface of the same name,
and can produce spurious semantic error messages. Extend the
characterization and checking code for such things, and the utility
functionns on which they depend, to dig through generics when they
occlude interface-defining subprograms. This is done on demand in
checking code, not once during name resolution, because the
procedures in question may also be forward-referenced.
Differential Revision: https://reviews.llvm.org/D131105
diff --git a/flang/include/flang/Semantics/symbol.h b/flang/include/flang/Semantics/symbol.h
index e79f8ab6503e..0b03bf06eb73 100644
--- a/flang/include/flang/Semantics/symbol.h
Remove a lambda capture of "[this]" in two cases where it
is no longer required. Will be pushed without waiting for
review if CI is successful in order to resolve a sad build bot.
Differential Revision: https://reviews.llvm.org/D131506
Intrinsic procedures in intrinsic modules that have (or better, *are*) generic interfaces
must not have specific procedures with the same name according to the Fortran
standard (17.11.1); i.e., a user program is allowed to define a procedure
of the same name as one of these generic interfaces, even when the generic is
in scope.
Differential Revision: https://reviews.llvm.org/D131108
Allow internal I/O to support non-default kinds of CHARACTER.
The I/O runtime design anticipated this standard feature, but
this patch is somewhat larger than I thought it would be because
many code sites had to have assumptions about units (characters
vs. bytes) brought into harmony, and some encoding utilities
had to be pulled out of IoStatementState and templatized into
their own new header file so that they are available to formatted
output code without having to "thread" an IoStatementState reference
through many call chains.
Differential Revision: https://reviews.llvm.org/D131107
When a procedure pointer references a function as its interface, don't
apply semantic checks to the specification expressions that appear in
the declaration of the function's result -- this can lead to bogus
error messages as those specification expressions are being examined
out of their proper context.
Differential Revision: https://reviews.llvm.org/D131106
Type-bound procedure bindings that specify intrinsic procedures as their
interfaces should not acquire the ELEMENTAL attribute from the purposes
of compatibility checking between inherited bindings and their overrides
in extended derived types.
Differential Revision: https://reviews.llvm.org/D131104
Defined generic procedure interfaces are allowed to shadow non-generic
procedures of the same name in the same scope (whether or not
that non-generic procedure is a specific procedure of the generic).
When making a copy of a generic interface symbol so that it can
be locally modified or be merged with another generic, don't forget
about the homonymous non-generic procedure that it might shadow.
Differential Revision: https://reviews.llvm.org/D131103
Inaccessible components -- those declared PRIVATE in another module -- should
be allowed to be redeclared in extended types, and should be ignored if
they appear as keywords in structure constructors.
Differential Revision: https://reviews.llvm.org/D131102
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
This utility routine in constant folding should return false when
a DIM= actual argument to a reduction intrinsic function has a
value that prevents folding, and true when folding can proceed.
The implementation was returning true in cases where a DIM=
argument was present but not constant.
Clarify the code and add commentary: a true result means that
there is no DIM= actual argument present, or that a DIM= argument
exists, is constant, and has a value that is in range.
Differential Revision: https://reviews.llvm.org/D131101
When a procedure pointer component has an interface that is a forward
reference to a procedure, syntax errors can be emitted if there is
a structure constructor that tries to initialize that component,
since its characteristics are not yet known; however, when the
initializer is a bare NULL(with no mold), those characteristics
don't matter. Make the characterization of the procedure pointer
component take place only when needed.
Differential Revision: https://reviews.llvm.org/D131100
The suffix is only added then the path the (lld-)link.exe is fully
resolved. Otherwise it may stay "link" or "lld-link".
On non-Windows platforms, lld-link also exists as a symbolic link to
lld, such that the full the path to lld-link might also be resolved
without .exe suffix in this case.
Note that CLANG_DEFAULT_LINKER could be set to other linkers such as
mold, in which case the test may still fail. This also applies to the
non-Windows tests that require "ld" in the linker name.
Fixes issue #56955
With this change all supported pgmath functions for non-complex
data types are replaced with either libm calls or MLIR operations,
except for MOD and some flavors of POW, which are going to be addressed
by other commits.
At the current stage a few math intrinsics are lowered into libm calls
always. When appropriate MLIR operation are available, the table can be
updated to generate them.
This patch serves two main purposes:
Firstly, to split some of the logic into a seperate method
to try and improve readability
On top of this, it aims to make creating the reductions more generic.
That way, subsequent patches adding reductions shouldn't need
to add a significant amount of extra logic checks, such as checking
for specific operators.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D131161
Dominik Adamski