| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
I used the codemod python tool to do this with the following commands:
codemod 'tensorflow/mlir/blob/master/include' 'llvm/llvm-project/blob/master/mlir/include'
codemod 'tensorflow/mlir/blob/master' 'llvm/llvm-project/blob/master/mlir'
codemod 'tensorflow/mlir' 'llvm-project/llvm'
Differential Revision: https://reviews.llvm.org/D72244
|
|
|
|
|
|
|
|
|
|
| |
properly value-typed.
Summary: These were temporary methods used to simplify the transition.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D72548
|
|
|
|
|
|
| |
ValuePtr was a temporary typedef during the transition to a value-typed Value.
PiperOrigin-RevId: 286945714
|
|
|
|
| |
PiperOrigin-RevId: 286906740
|
|
|
|
|
|
|
|
|
|
| |
Value being value-typed.
This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ
This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics.
PiperOrigin-RevId: 286844725
|
|
|
|
|
|
|
| |
GCC is unable to properly implicitly capture 'this' in generic lambdas. This bug is not fixed until 7.1.0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67274
PiperOrigin-RevId: 286083427
|
|
|
|
| |
PiperOrigin-RevId: 286066371
|
|
|
|
|
|
|
| |
Closes tensorflow/mlir#306
COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/306 from shanshanpt:master 11430c2131281d84a432f45e854e29917b336e8d
PiperOrigin-RevId: 284613648
|
|
|
|
|
|
| |
Closes tensorflow/mlir#304
PiperOrigin-RevId: 284568358
|
|
|
|
|
|
|
| |
Closes tensorflow/mlir#290
COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/290 from kiszk:spelling_tweaks_201912 9d9afd16a723dd65754a04698b3976f150a6054a
PiperOrigin-RevId: 284169681
|
|
|
|
|
|
|
| |
Closes tensorflow/mlir#250
COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/250 from kiszk:spelling_tweaks_201911 50fc04443723190b764e824b6fcd2469fecb56e6
PiperOrigin-RevId: 283733032
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM IR supports linkage on global objects such as global variables and
functions. Introduce the Linkage attribute into the LLVM dialect, backed by an
integer storage. Use this attribute on LLVM::GlobalOp and make it mandatory.
Implement parsing/printing of the attribute and conversion to LLVM IR.
See tensorflow/mlir#277.
PiperOrigin-RevId: 283309328
|
|
|
|
|
|
| |
Support for including a file multiple times was added in tablegen, removing the need for these extra guards. This is because we already insert c/c++ style header guards within each of the specific .td files.
PiperOrigin-RevId: 282076728
|
|
|
|
| |
PiperOrigin-RevId: 280888290
|
|
|
|
|
|
| |
correctness.
PiperOrigin-RevId: 280678392
|
|
|
|
|
|
|
| |
This is essentially a dialect conversion and conceptually belongs to
conversions.
PiperOrigin-RevId: 280460034
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows for adding additional nested references to a SymbolRefAttr to allow for further resolving a symbol if that symbol also defines a SymbolTable. If a referenced symbol also defines a symbol table, a nested reference can be used to refer to a symbol within that table. Nested references are printed after the main reference in the following form:
symbol-ref-attribute ::= symbol-ref-id (`::` symbol-ref-id)*
Example:
module @reference {
func @nested_reference()
}
my_reference_op @reference::@nested_reference
Given that SymbolRefAttr is now more general, the existing functionality centered around a single reference is moved to a derived class FlatSymbolRefAttr. Followup commits will add support to lookups, rauw, etc. for scoped references.
PiperOrigin-RevId: 279860501
|
|
|
|
|
|
|
|
| |
Toy tutorial compiler
Fix tensorflow/mlir#229
PiperOrigin-RevId: 279557863
|
|
|
|
|
|
| |
This chapter adds a new composite type to Toy, and shows the process of adding a new type to the IR, adding and updating operations to use it, and constant folding operations producing it.
PiperOrigin-RevId: 279107885
|
|
|
|
|
|
| |
Use header blocks to separate operation implementations, and switch the build methods to be out-of-line when possible.
PiperOrigin-RevId: 278982913
|
|
|
|
|
|
| |
bit of the implementation.
PiperOrigin-RevId: 278982817
|
|
|
|
|
|
|
|
|
|
| |
Upstream LLVM gained support for #ifndef with https://reviews.llvm.org/D61888
This is changed mechanically via the following command:
find . -name "*.td" -exec sed -i -e ':a' -e 'N' -e '$!ba' -e 's/#ifdef \([A-Z_]*\)\n#else/#ifndef \1/g' {} \;
PiperOrigin-RevId: 277789427
|
|
|
|
|
|
| |
This allows for them to be used on other non-function, or even other function-like, operations. The algorithms are already generic, so this is simply changing the derived pass type. The majority of this change is just ensuring that the nesting of these passes remains the same, as the pass manager won't auto-nest them anymore.
PiperOrigin-RevId: 276573038
|
|
|
|
|
|
| |
This was used for shape inference in the previous tutorial flow.
PiperOrigin-RevId: 276351916
|
|
|
|
|
|
| |
This change rewrites Ch-4.md to introduced interfaces in a detailed step-by-step manner, adds examples, and fixes some errors.
PiperOrigin-RevId: 275887017
|
|
|
|
|
|
| |
MulOp now represents an element-wise multiplication instead of a matrix multiplication.
PiperOrigin-RevId: 275886774
|
|
|
|
|
|
| |
Closes tensorflow/mlir#175
PiperOrigin-RevId: 275726876
|
|
|
|
| |
PiperOrigin-RevId: 275659433
|
|
|
|
| |
PiperOrigin-RevId: 275631166
|
|
|
|
|
|
| |
These don't add any value, and some are even more restrictive than the respective static 'get' method.
PiperOrigin-RevId: 275391240
|
|
|
|
|
|
| |
This chapters introduces the notion of a full conversion, and adds support for lowering down to the LLVM dialect, LLVM IR, and thus code generation.
PiperOrigin-RevId: 275337786
|
|
|
|
|
|
| |
The transpose in the example had the same result type as its input, which is incorrect.
PiperOrigin-RevId: 275186568
|
|
|
|
|
|
| |
This chapter adds a partial lowering of toy operations, all but PrintOp, to a combination of the Affine and Std dialects. This chapter focuses on introducing the conversion framework, the benefits of partial lowering, and how easily dialects may co-exist in the IR.
PiperOrigin-RevId: 275150649
|
|
|
|
|
|
| |
The GenericCallOp needed to have the CallOpInterface to be picked up by the inliner. This also adds a CastOp to perform shape casts that are generated during inlining. The casts generated by the inliner will be folded away after shape inference.
PiperOrigin-RevId: 275150438
|
|
|
|
| |
PiperOrigin-RevId: 275147795
|
|
|
|
|
|
| |
This change performs general cleanups of the implementation of ch.4 and fixes some bugs. For example, the operations currently don't inherit from the shape inference interface.
PiperOrigin-RevId: 275089914
|
|
|
|
|
|
|
|
|
|
| |
This Chapter now introduces and makes use of the Interface concept
in MLIR to demonstrate ShapeInference.
END_PUBLIC
Closes tensorflow/mlir#191
PiperOrigin-RevId: 275085151
|
|
|
|
|
|
| |
These traits are added in chapter 3 when we begin discussion optimization on the toy operations.
PiperOrigin-RevId: 274974010
|
|
|
|
|
|
| |
This change refactors the toyc driver to be much cleaner and easier to extend. It also cleans up a few comments in the combiner.
PiperOrigin-RevId: 274973808
|
|
|
|
|
|
| |
This fixes an issue with make where it fails to properly handle the dependency ordering.
PiperOrigin-RevId: 274897702
|
|
|
|
|
|
|
|
|
| |
This is using Table-driven Declarative Rewrite Rules (DRR), the previous
version of the tutorial only showed the C++ patterns.
Closes tensorflow/mlir#187
PiperOrigin-RevId: 274852321
|
|
|
|
|
|
| |
This effectively rewrites Ch.2 to introduce dialects, operations, and registration instead of deferring to Ch.3. This allows for introducing the best practices up front(using ODS, registering operations, etc.), and limits the opaque API to the chapter document instead of the code.
PiperOrigin-RevId: 274724289
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function-like operation allows one to define functions that have wrapped
LLVM IR function type, in particular variadic functions. The operation was
added in parallel to the existing lowering flow, this commit only switches the
flow to use it.
Using a custom function type makes the LLVM IR dialect type system more
consistent and avoids complex conversion rules for functions that previously
had to use the built-in function type instead of a wrapped LLVM IR dialect type
and perform conversions during the analysis.
PiperOrigin-RevId: 273910855
|
|
|
|
| |
PiperOrigin-RevId: 272851237
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RFC for unifying Linalg and Affine compilation passes into an end-to-end flow with a predictable ABI and linkage to external function calls raised the question of why we have variable sized descriptors for memrefs depending on whether they have static or dynamic dimensions (https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/MaL8m2nXuio).
This CL standardizes the ABI on the rank of the memrefs.
The LLVM struct for a memref becomes equivalent to:
```
template <typename Elem, size_t Rank>
struct {
Elem *ptr;
int64_t sizes[Rank];
};
```
PiperOrigin-RevId: 270947276
|
|
|
|
|
|
| |
Operation (NFC)
PiperOrigin-RevId: 270727180
|
|
|
|
|
|
| |
MLIR follows the LLVM convention of passing by reference instead of by pointer.
PiperOrigin-RevId: 270396945
|
|
|
|
| |
PiperOrigin-RevId: 269803466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change generalizes the structure of the pass manager to allow arbitrary nesting pass managers for other operations, at any level. The only user visible change to existing code is the fact that a PassManager must now provide an MLIRContext on construction. A new class `OpPassManager` has been added that represents a pass manager on a specific operation type. `PassManager` will remain the top-level entry point into the pipeline, with OpPassManagers being nested underneath. OpPassManagers will still be implicitly nested if the operation type on the pass differs from the pass manager. To explicitly build a pipeline, the 'nest' methods on OpPassManager may be used:
// Pass manager for the top-level module.
PassManager pm(ctx);
// Nest a pipeline operating on FuncOp.
OpPassManager &fpm = pm.nest<FuncOp>();
fpm.addPass(...);
// Nest a pipeline under the FuncOp pipeline that operates on spirv::ModuleOp
OpPassManager &spvModulePM = pm.nest<spirv::ModuleOp>();
// Nest a pipeline on FuncOps inside of the spirv::ModuleOp.
OpPassManager &spvFuncPM = spvModulePM.nest<FuncOp>();
To help accomplish this a new general OperationPass is added that operates on opaque Operations. This pass can be inserted in a pass manager of any type to operate on any operation opaquely. An example of this opaque OperationPass is a VerifierPass, that simply runs the verifier opaquely on the current operation.
/// Pass to verify an operation and signal failure if necessary.
class VerifierPass : public OperationPass<VerifierPass> {
void runOnOperation() override {
Operation *op = getOperation();
if (failed(verify(op)))
signalPassFailure();
markAllAnalysesPreserved();
}
};
PiperOrigin-RevId: 266840344
|
|
|
|
|
|
|
|
| |
The code and documentation for this chapter of the tutorial have been updated to follow the new flow. The toy 'array' type has been replaced by usages of the MLIR tensor type. The code has also been cleaned up and modernized.
Closes tensorflow/mlir#101
PiperOrigin-RevId: 265744086
|