summaryrefslogtreecommitdiffstats
path: root/mlir/test/lib/Transforms/TestLoopParametricTiling.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Refactor the way that pass options are specified.River Riddle2019-12-231-15/+9
| | | | | | | | | This change refactors pass options to be more similar to how statistics are modeled. More specifically, the options are specified directly on the pass instead of in a separate options class. (Note that the behavior and specification for pass pipelines remains the same.) This brings about several benefits: * The specification of options is much simpler * The round-trip format of a pass can be generated automatically * This gives a somewhat deeper integration with "configuring" a pass, which we could potentially expose to users in the future. PiperOrigin-RevId: 286953824
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-231-13/+4
| | | | PiperOrigin-RevId: 286906740
* Add Instance Specific Pass Options.MLIR Team2019-10-081-13/+15
| | | | | | | | | | | | | | | | This allows individual passes to define options structs and for these options to be parsed per instance of the pass while building the pass pipeline from the command line provided textual specification. The user can specify these per-instance pipeline options like so: ``` struct MyPassOptions : public PassOptions<MyPassOptions> { Option<int> exampleOption{*this, "flag-name", llvm::cl::desc("...")}; List<int> exampleListOption{*this, "list-flag-name", llvm::cl::desc("...")}; }; static PassRegistration<MyPass, MyPassOptions> pass("my-pass", "description"); ``` PiperOrigin-RevId: 273650140
* NFC: Finish replacing FunctionPassBase/ModulePassBase with OpPassBase.River Riddle2019-09-131-1/+1
| | | | | | These directives were temporary during the generalization of FunctionPass/ModulePass to OpPass. PiperOrigin-RevId: 268970259
* Refactor the 'walk' methods for operations.River Riddle2019-08-291-1/+1
| | | | | | | | | | | | This change refactors and cleans up the implementation of the operation walk methods. After this refactoring is that the explicit template parameter for the operation type is no longer needed for the explicit op walks. For example: op->walk<AffineForOp>([](AffineForOp op) { ... }); is now accomplished via: op->walk([](AffineForOp op) { ... }); PiperOrigin-RevId: 266209552
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-171-2/+2
| | | | | | | | Switch to C++14 standard method as llvm::make_unique has been removed ( https://reviews.llvm.org/D66259). Also mark some targets as c++14 to ease next integrates. PiperOrigin-RevId: 263953918
* Express ownership transfer in PassManager API through std::unique_ptr (NFC)Mehdi Amini2019-08-121-3/+4
| | | | | | | | | | | | | | 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: Standardize the terminology used for parent ops/regions/etc.River Riddle2019-08-091-1/+1
| | | | | | There are currently several different terms used to refer to a parent IR unit in 'get' methods: getParent/getEnclosing/getContaining. This cl standardizes all of these methods to use 'getParent*'. PiperOrigin-RevId: 262680287
* Refactor LoopParametricTiling as a test pass - NFCNicolas Vasilache2019-07-221-0/+71
This CL moves LoopParametricTiling into test/lib as a pass for purely testing purposes. PiperOrigin-RevId: 259300264
OpenPOWER on IntegriCloud