summaryrefslogtreecommitdiffstats
path: root/mlir/examples/toy/Ch4/toyc.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-231-13/+4
| | | | PiperOrigin-RevId: 286906740
* Fix segfault (nullptr dereference) when passing a non-existent file to the ↵Mehdi Amini2019-11-091-0/+2
| | | | | | | | Toy tutorial compiler Fix tensorflow/mlir#229 PiperOrigin-RevId: 279557863
* NFC: Uniformize parser naming scheme in Toy tutorial to camelCase and tidy a ↵River Riddle2019-11-061-7/+7
| | | | | | bit of the implementation. PiperOrigin-RevId: 278982817
* Convert the Canonicalize and CSE passes to generic Operation Passes.River Riddle2019-10-241-3/+4
| | | | | | 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
* Cleanup and rewrite Ch-4.md.River Riddle2019-10-211-0/+1
| | | | | | 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
* Add SourceMgrDiagnosticHandler to toyJacques Pienaar2019-10-191-3/+5
| | | | PiperOrigin-RevId: 275659433
* Add support for inlining toy call operations.River Riddle2019-10-161-3/+1
| | | | | | 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
* Update Chapter 4 of the Toy tutorialSana Damani2019-10-161-40/+49
| | | | | | | | | | 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
* Refactor the pass manager to support operations other than FuncOp/ModuleOp.River Riddle2019-09-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Express ownership transfer in PassManager API through std::unique_ptr (NFC)Mehdi Amini2019-08-121-0/+1
| | | | | | | | | | | | | | Since raw pointers are always passed around for IR construct without implying any ownership transfer, it can be error prone to have implicit ownership transferred the same way. For example this code can seem harmless: Pass *pass = .... pm.addPass(pass); pm.addPass(pass); pm.run(module); PiperOrigin-RevId: 263053082
* NFC: Remove redundant call to registerPassManagerCLOptions from MLIR tutorialSmit Hinsu2019-07-121-3/+0
| | | | | | | main already calls registerPassManagerCLOptions. TESTED = not (NFC) PiperOrigin-RevId: 257722013
* NFC: Rename Module to ModuleOp.River Riddle2019-07-101-1/+1
| | | | | | Module is a legacy name that only exists as a typedef of ModuleOp. PiperOrigin-RevId: 257427248
* NFC: Move the Function/Module/Operation::verify methods out-of-line.River Riddle2019-07-021-1/+2
| | | | | | As Functions/Modules becomes operations, these methods will conflict with the 'verify' hook already on derived operation types. PiperOrigin-RevId: 256246112
* NFC: Refactor Module to be value typed.River Riddle2019-07-021-4/+4
| | | | | | As with Functions, Module will soon become an operation, which are value-typed. This eases the transition from Module to ModuleOp. A new class, OwningModuleRef is provided to allow for owning a reference to a Module, and will auto-delete the held module on destruction. PiperOrigin-RevId: 256196193
* Add Chapter 4 for the Toy tutorial: shape inference, function ↵Mehdi Amini2019-04-051-0/+164
specialization, and basic combines -- PiperOrigin-RevId: 242050514
OpenPOWER on IntegriCloud