A fully fledged LLVM inliner will require a lot of logic. Since
`LLVMDialect.cpp` is large enough as it is, preemptively outline the
inlining logic into a separate `.cpp` file. This will also allow us to
add a `DEBUG_TYPE` for debugging the inliner.
The name `LLVMInlining` was chosen over `LLVMInlinerInterface` to keep
the option open for exposing inlining functionality even when not
invoked through the `DialectInlinerInterface`.
Depends on D146616
Reviewed By: gysit
Differential Revision: https://reviews.llvm.org/D146628
These patterns follow FoldMemRefAliasOps which is further refactored for reuse.
In the process, fix FoldMemRefAliasOps handling of strides for vector.transfer ops which was previously incorrect.
These opt-in patterns generalize the existing canonicalizations on vector.transfer ops.
In the future the blanket canonicalizations will be retired.
They are kept for now to minimize porting disruptions.
Differential Revision: https://reviews.llvm.org/D146624
The old implementation parsed the optional attribute dict, only to replace its
contents by using `assign`.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D146707
`BoundType` is no longer a nested member of `IntegerRelation` but a top-level enum in the `presburger` namespace.
This allows `BoundType` to be predeclared in header files. Nested members cannot be predeclared.
Differential Revision: https://reviews.llvm.org/D146210
Fix bug and MSAN issue in affine loop utils introduced by
d25e022cd1 (D146495). While on it,
fix/clean up issues in immediately surrounding code.
Differential Revision: https://reviews.llvm.org/D146698
The new class hierarchy is as follows:
* `IntegerRelation` (no change)
* `IntegerPolyhedron` (no change)
* `FlatLinearConstraints`: provides an AffineExpr-based API
* `FlatLinearValueConstraints`: stores an additional mapping of non-local vars to SSA values
* `FlatAffineValueConstraints`: provides additional helper functions for Affine dialect ops
* `FlatAffineRelation` (no change)
`FlatConstraints` and `FlatValueConstraints` are moved from `MLIRAffineAnalysis` to `MLIRAnalysis` and can be used without depending on the Affine dialect.
This change is in preparation of D145681, which adds an MLIR interface that depends on `FlatConstraints` (and cannot depend on the Affine dialect or any other dialect).
Differential Revision: https://reviews.llvm.org/D146201
This patch introduces the poison constant from LLVM in the LLVM IR dialect. It also adds import and export support for it, along with roundtrip tests.
Reviewed By: gysit
Differential Revision: https://reviews.llvm.org/D146631
TOSA now specifies rounding of ties to even in section 1.8.2., "Main Inference Profile"
Reviewed By: eric-k256, rsuderman
Differential Revision: https://reviews.llvm.org/D146617
This includes standard LIT tests and integration tests with the LLVM CPU
runner.
I plan to use this to implement `sitofp` in D146597.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D146606
Adds a canonicalizer for the concatenate->slice sequence where
an output of slice can be replaced with an input of concatenate.
This is useful in the context of operations with complex inputs
and outputs that are legalized from a framework such as TFL.
For example, a TFL graph (FFT->FFT) will be legalized to the
following TOSA graph:
<complex input>
/ \
slice slice
\ /
FFT
/ \ -+
concatenate |
/ \ | Redundant
slice slice |
\ / -+
FFT
/ \
concatenate
|
<complex output>
Concatenate and slice operations at the boundaries of the graph are
useful as they maintain the correct correspondance of input/output
tensors to the original TFL graph. However, consecutive
complex operations will result in redundant concatenate->slice
sequences which should be removed from the final TOSA graph.
The canonicalization does not currently handle dynamic types.
Signed-off-by: Luke Hutton <luke.hutton@arm.com>
Reviewed By: rsuderman
Differential Revision: https://reviews.llvm.org/D144545
Support inlining of function calls with the byval attribute on function
arguments by copying the pointee into a newly alloca'ed pointer at the
callsite before inlining.
The alignment attribute is not yet taken into account.
Reviewed By: ftynse, gysit
Differential Revision: https://reviews.llvm.org/D146616
The default behavior of getProjectedMap may be surprising as it implicitly compresses the dims and
the unused symbols.
Make these explicit in the API and refactor to more idiomatic implementations with better reuse.
Differential Revision: https://reviews.llvm.org/D146611
The revision adds the llvm.experimental.noalias.scope.decl intrinsic
to the LLVM dialect and updates the import and export accordingly.
Reviewed By: Dinistro
Differential Revision: https://reviews.llvm.org/D146504
The constructor of `OperationFolder` takes a listener. Therefore, the remaining API should not take any builder/rewriters. This could lead to double notifications in case a listener is attached to the builder/rewriter.
As an internal cleanup, `OperationFolder` now has an `IRRewriter` instead of a `RewriterBase::Listener`. In most cases, `OperationFolder` no longer has to notify/deal with listeners. This is done by the rewriter.
Differential Revision: https://reviews.llvm.org/D146134
The revision adds the handleArgument and handleResult handlers that
allow users of the inlining interface to implement argument and result
conversions that take argument and result attributes into account. The
motivating use cases for this revision are taken from the LLVM dialect
inliner, which has to copy arguments that are marked as byval and that
also has to consider zeroext / signext when converting integers.
All type conversions are currently handled by the
materializeCallConversion hook. It runs before isLegalToInline and
supports only the introduction of a single cast operation since it may
have to rollback. The new handlers run shortly before and after
inlining and cannot fail. As a result, they can introduce more complex
ir such as copying a struct argument. At the moment, the new hooks
cannot be used to perform type conversions since all type conversions
have to be done using the materializeCallConversion. A follow up
revision will either relax this constraint or drop
materializeCallConversion in favor of the new and more flexible
handlers.
The revision also extends the CallableOpInterface to provide access
to the argument and result attributes if available.
Reviewed By: rriddle, Dinistro
Differential Revision: https://reviews.llvm.org/D145582
Blocks are enumerated depth-first, but post-order. I.e., a block is enumerated when its successors have been enumerated. This iteration style is suitable when deleting blocks in a regions: in the absence of cycles, uses are deleted before their definitions.
Differential Revision: https://reviews.llvm.org/D146125
Creating maximally folded and composd affine.apply operation during
FoldMemRefAliasOps composes better with other transformations without having
to interleave canonicalization passes.
Differential Revision: https://reviews.llvm.org/D146515
Some uses of TOSA rely on the constant operands of particular operations,
e.g. paddings and pad_const in pad op. Add a verification pattern in the
validation pass, and this is optionally enabled.
Change-Id: I1628c0840a27ab06ef91150eee56ad4f5ac9543d
Reviewed By: rsuderman
Differential Revision: https://reviews.llvm.org/D145412
When this interface is used, a call to inferReturnTypeComponents()
is generated on creation and verification of the op.
A few changes were required in inferReturnTypeComponents():
- Emit error when it fails.
The verifier calls this method now, and it is preferable to
indicate what caused the failure.
- Fix the inferred return shapes so they have a type too.
Reviewed By: rsuderman
Differential Revision: https://reviews.llvm.org/D146132
Named sequences introduce an additional abstraction and reuse capability
to the transform dialect. They can be though of as macros parameterized
with handles that can be invoked in places where a transform dialect
operation is expected. Such reuse was previously not possible in the
dialect and required dynamic construction of the transform IR from the
client language. Named sequences are intentionally restricted to
disallow recursion, as it could make the dialect accidentally
Turing-complete, which isn't desired at this point.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D146433
This patch adds alloca address space information to the data layout interface
and implementation in the DLTI dialect. This is needed for targets that use
separate address spaces for local/stack data.
Reviewed By: ftynse, krzysz00
Differential Revision: https://reviews.llvm.org/D144657
This patch supports the processing of dialect attributes attached to top-level
module-type operations during MLIR-to-LLVMIR lowering.
This approach modifies the `mlir::translateModuleToLLVMIR()` function to call
`ModuleTranslation::convertOperation()` on the top-level operation, after its
body has been lowered. This, in turn, will get the
`LLVMTranslationDialectInterface` object associated to that operation's dialect
before trying to use it for lowering prior to processing dialect attributes
attached to the operation.
Since there are no `LLVMTranslationDialectInterface`s for the builtin and GPU
dialects, which define their own module-type operations, this patch also adds
and registers them. The requirement for always calling
`mlir::registerBuiltinDialectTranslation()` before any translation of MLIR to
LLVM IR where builtin module operations are present is introduced. The purpose
of these new translation interfaces is to succeed when processing module-type
operations, allowing the lowering process to continue and to prevent the
introduction of failures related to not finding such interfaces.
Differential Revision: https://reviews.llvm.org/D145932
Fix warnings in AttrTypeSubElements.h (below) with GCC 9.4.0.
```
mlir/lib/IR/ExtensibleDialect.cpp:443:62: required from here
mlir/include/mlir/IR/AttrTypeSubElements.h:412:37: warning: parameter ‘derived’ set but not used [-Wunused-but-set-parameter]
412 | void walkImmediateSubElementsImpl(T derived,
| ~~^~~
```
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D146107
This improves namespacing, and follows the pattern used for "Kind" enums elsewhere in MLIR.
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D146086
Pad tiling implementation only needs to return the tiled pad
operation. The rest of the generated code is related to handling
boundary conditions.
Reviewed By: hanchung
Differential Revision: https://reviews.llvm.org/D146439
Introduce the possibility to load/store scalars via amdgpu.raw_buffer_{load,store}
Reviewed By: krzysz00
Differential Revision: https://reviews.llvm.org/D146413
This patch adds OpenMP IRBuilder support for the Target Data directives to allow lowering to LLVM IR.
The mlir::Translation is responsible for generating supporting code for processing the map_operands through the processMapOperand function, and also generate code for the r>
The OMPIRBuilder is responsible for generating the begin and end mapper function calls.
Limitations:
- use_device_ptr and use_device_addr clauses are NOT supported for Target Data operation.
- nowait clauses are NOT supported for Target Enter and Exit Data operations.
- Only LLVMPointerType is supported for map_operands.
Differential Revision: https://reviews.llvm.org/D142914
