summaryrefslogtreecommitdiffstats
path: root/mlir/examples/toy/Ch5
Commit message (Collapse)AuthorAgeFilesLines
...
* NFC: Rename Function to FuncOp.River Riddle2019-07-103-16/+16
| | | | PiperOrigin-RevId: 257293379
* NFC: Remove `Module::getFunctions` in favor of a general `getOps<T>`.River Riddle2019-07-082-4/+5
| | | | | | Modules can now contain more than just Functions, this just updates the iteration API to reflect that. The 'begin'/'end' methods have also been updated to iterate over opaque Operations. PiperOrigin-RevId: 257099084
* NFC: Remove the various "::getFunction" methods.River Riddle2019-07-081-1/+1
| | | | | | These methods assume that a function is a valid builtin top-level operation, and removing these methods allows for decoupling FuncOp and IR/. Utility "getParentOfType" methods have been added to Operation/OpState to allow for querying the first parent operation of a given type. PiperOrigin-RevId: 257018913
* Replace the implementation of Function and Module with FuncOp and ModuleOp.River Riddle2019-07-031-2/+3
| | | | | | This is an important step in allowing for the top-level of the IR to be extensible. FuncOp and ModuleOp contain all of the necessary functionality, while using the existing operation infrastructure. As an interim step, many of the usages of Function and Module, including the name, will remain the same. In the future, many of these will be relaxed to allow for many different types of top-level operations to co-exist. PiperOrigin-RevId: 256427100
* NFC: Move the Function/Module/Operation::verify methods out-of-line.River Riddle2019-07-023-4/+7
| | | | | | 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-025-21/+20
| | | | | | 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
* NFC: Refactor Function to be value typed.River Riddle2019-07-013-51/+53
| | | | | | Move the data members out of Function and into a new impl storage class 'FunctionStorage'. This allows for Function to become value typed, which will greatly simplify the transition of Function to FuncOp(given that FuncOp is also value typed). PiperOrigin-RevId: 255983022
* Extract the automatic function renaming and symbol table out of Module.River Riddle2019-07-011-7/+9
| | | | | | This functionality is now moved to a new class, ModuleManager. This class allows for inserting functions into a module, and will auto-rename them on insert to ensure a unique name. This now means that users adding new functions to a module must ensure that the function name is unique, as the Module will no longer do it automatically. This also means that Module::getNamedFunction now operates in O(N) instead of the O(c) time it did before. This simplifies the move of Modules to Operations as the ModuleOp will not be able to have this functionality. PiperOrigin-RevId: 255846088
* Refactor DialectConversion to use 'materializeConversion' when a type ↵River Riddle2019-06-281-0/+8
| | | | | | | | conversion must persist after the conversion has finished. During conversion, if a type conversion has dangling uses a type conversion must persist after conversion has finished to maintain valid IR. In these cases, we now query the TypeConverter to materialize a conversion for us. This allows for the default case of a full conversion to continue working as expected, but also handle the degenerate cases more robustly. PiperOrigin-RevId: 255637171
* Move the emitError/Warning/Remark utility methods out of MLIRContext and ↵River Riddle2019-06-255-51/+35
| | | | | | | | into the mlir namespace. Now that Locations are attributes, they have direct access to the MLIR context. This allows for simplifying error emission by removing unnecessary context lookups. PiperOrigin-RevId: 255112791
* NFC: Uniformize the return of the LocationAttr 'get' methods to 'Location'.River Riddle2019-06-251-1/+1
| | | | PiperOrigin-RevId: 255078768
* Replace usages of 'UniquedFilename' with 'Identifier' and remove it. ↵River Riddle2019-06-191-3/+2
| | | | | | Identifier already contains all of the necessary functionality/verification, so having a separate class for filenames is unnecessary. PiperOrigin-RevId: 253855505
* Remove dead code.Jing Pu2019-06-191-11/+0
| | | | PiperOrigin-RevId: 253314416
* NFC: Cleanup the naming scheme for registering legalization actions to be ↵River Riddle2019-06-112-3/+3
| | | | | | consistent, and move a file functions to the source file. PiperOrigin-RevId: 252639629
* Remove the ability to directly construct a DenseElementsAttr with a raw ↵River Riddle2019-06-091-2/+1
| | | | | | | | | character buffer. This made assumptions about how DenseElementsAttr structured its internal storage, which may change in the future. To replace the existing use cases, a few utility methods have been added: * 'get' methods that allow constructing from an ArrayRef of integer or floating point values. * A 'reshape' method to allow for changing the shape without changing the underlying data. PiperOrigin-RevId: 252067898
* Add support for matchAndRewrite to the DialectConversion patterns. This also ↵River Riddle2019-06-092-12/+18
| | | | | | drops the default "always succeed" match override to better align with RewritePattern. PiperOrigin-RevId: 251941625
* NFC: Rename FuncBuilder to OpBuilder and refactor to take a top level region ↵River Riddle2019-06-094-10/+10
| | | | | | instead of a function. PiperOrigin-RevId: 251563898
* Refactor the dialect conversion framework to support multi-level ↵River Riddle2019-06-032-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | conversions. Multi-level conversions are those that require multiple patterns to be applied before an operation is completely legalized. This essentially means that conversion patterns do not have to directly generate legal operations, and may be chained together to produce legal code. To accomplish this, moving forward users will need to provide a legalization target that defines what operations are legal for the conversion. A target can mark an operation as legal by providing a specific legalization action. The initial actions are: * Legal - This action signals that every instance of the given operation is legal, i.e. any combination of attributes, operands, types, etc. is valid. * Dynamic - This action signals that only some instances of a given operation are legal. This allows for defining fine-tune constraints, like say std.add is only legal when operating on 32-bit integers. An example target is shown below: struct MyTarget : public ConversionTarget { MyTarget(MLIRContext &ctx) : ConversionTarget(ctx) { // All operations in the LLVM dialect are legal. addLegalDialect<LLVMDialect>(); // std.constant op is always legal on this target. addLegalOp<ConstantOp>(); // std.return op has dynamic legality constraints. addDynamicallyLegalOp<ReturnOp>(); } /// Implement the custom legalization handler to handle /// std.return. bool isLegal(Operation *op) override { // Process the dynamic handling for a std.return op (and any others that were // marked "dynamic"). ... } }; PiperOrigin-RevId: 251289374
* Replace a usage of std::vector with SmallVector to allow constructing ↵River Riddle2019-06-011-5/+3
| | | | | | | | with non-constant iterators on MSVC. -- PiperOrigin-RevId: 250769027
* Add a templated wrapper around RewritePattern that allows for defining ↵River Riddle2019-06-011-62/+41
| | | | | | | | match/rewrite methods with an instance of the source op instead of a raw Operation*. -- PiperOrigin-RevId: 250003405
* Rename DialectConversion to TypeConverter and split out pattern ↵River Riddle2019-06-012-38/+17
| | | | | | | | construction. This simplifies building the conversion pattern list from multiple sources. -- PiperOrigin-RevId: 249930583
* Add operand type iterators to Operation and cleanup usages of ↵River Riddle2019-06-011-8/+5
| | | | | | | | operand->getType. This also simplifies some lingering usages of result->getType. -- PiperOrigin-RevId: 249889174
* NFC: Rename DialectConversionPattern to ConversionPattern.River Riddle2019-06-012-18/+14
| | | | | | -- PiperOrigin-RevId: 249857277
* Decouple running a conversion from the DialectConversion class. The ↵River Riddle2019-06-012-3/+5
| | | | | | | | DialectConversion class is only necessary for type signature changes(block arguments or function arguments). This isn't always desired when performing a dialect conversion. This allows for those conversions without this need to run per function instead of per module. -- PiperOrigin-RevId: 249657549
* Add thread-safe utilities to LLVMType to allow constructing llvm types ↵River Riddle2019-06-011-7/+3
| | | | | | | | in a multi-threaded environment. The LLVMContext is not thread-safe and directly constructing a raw llvm::Type can create situations where the LLVMContext is modified by multiple threads at the same time. -- PiperOrigin-RevId: 249526233
* Fix a bug in toy LateLowering where a type conversion was using 'cast' ↵River Riddle2019-06-011-1/+1
| | | | | | | | instead of 'dyn_cast'. -- PiperOrigin-RevId: 249325111
* Use lambdas for nesting edsc constructs.Nicolas Vasilache2019-05-201-11/+12
| | | | | | | | | | | Using ArrayRef introduces issues with the order of evaluation between a constructor and the arguments of the subsequent calls to the `operator()`. As a consequence the order of captures is not well-defined can go wrong with certain compilers (e.g. gcc-6.4). This CL fixes the issue by using lambdas in lieu of ArrayRef. -- PiperOrigin-RevId: 249114775
* ExecutionEngine: drop PassManager integrationAlex Zinenko2019-05-201-5/+2
| | | | | | | | | | | | | | | Originally, ExecutionEngine was created before MLIR had a proper pass management infrastructure or an LLVM IR dialect (using the LLVM target directly). It has been running a bunch of lowering passes to convert the input IR from Standard+Affine dialects to LLVM IR and, later, to the LLVM IR dialect. This is no longer necessary and is even undesirable for compilation flows that perform their own conversion to the LLVM IR dialect. Drop this integration and make ExecutionEngine accept only the LLVM IR dialect. Users of the ExecutionEngine can call the relevant passes themselves. -- PiperOrigin-RevId: 249004676
* NFC: Tidy up DialectConversion.cpp and rename DialectOpConversion to ↵River Riddle2019-05-202-14/+18
| | | | | | | | DialectConversionPattern. -- PiperOrigin-RevId: 248980810
* Update the rewrite methods of each of the DialectConversion patterns to ↵River Riddle2019-05-201-6/+4
| | | | | | | | notify the PatternRewriter that the operation is being replaced. -- PiperOrigin-RevId: 248965082
* Move the ConversionListBuilder utility to PatternMatch.h and rename it ↵River Riddle2019-05-203-7/+6
| | | | | | | | to RewriteListBuilder. It has no specific functionality for DialectOpConversion patterns and can be useful for RewritePatterns in general. -- PiperOrigin-RevId: 248884466
* Rewrite the DialectOpConversion patterns to inherit from RewritePattern ↵River Riddle2019-05-202-37/+25
| | | | | | | | instead of Pattern. This simplifies the infrastructure a bit by being able to reuse PatternRewriter and the RewritePatternMatcher, but also starts to lay the groundwork for a more generalized legalization framework that can operate on DialectOpConversions as well as normal RewritePatterns. -- PiperOrigin-RevId: 248836492
* Fix lingering sign compare warnings in exposed by "ninja check-mlir".Stella Laurenzo2019-05-201-1/+1
| | | | | | -- PiperOrigin-RevId: 248050178
* Fix -Wsign-compare in Toy LateLowering.Jacques Pienaar2019-05-201-2/+2
| | | | | | -- PiperOrigin-RevId: 248005642
* Add a utility method to MLIRContext get a registered dialect with the ↵River Riddle2019-05-201-2/+2
| | | | | | | | | | | | | | derived type instead of the string name. The derived dialect type must provide a static 'getDialectNamespace' method. This means that we can now do something like: ctx->getRegisteredDialect<LLVMDialect>(); as opposed to: static_cast<LLVMDialect *>(ctx->getRegisteredDialect("llvm"); -- PiperOrigin-RevId: 247989896
* Remove the explicit "friend Operation" statement from each of the ↵River Riddle2019-05-201-10/+0
| | | | | | | | derived operations now that op casting is no longer inside of Operation. -- PiperOrigin-RevId: 247791672
* Replace Operation::isa with llvm::isa.River Riddle2019-05-201-1/+1
| | | | | | -- PiperOrigin-RevId: 247789235
* Replace Operation::cast with llvm::cast.River Riddle2019-05-204-12/+12
| | | | | | -- PiperOrigin-RevId: 247785983
* Add support for using llvm::dyn_cast/cast/isa for operation casts and ↵River Riddle2019-05-202-7/+7
| | | | | | | | replace usages of Operation::dyn_cast with llvm::dyn_cast. -- PiperOrigin-RevId: 247780086
* Automated rollback of changelist 247778391.MLIR Team2019-05-202-7/+7
| | | | PiperOrigin-RevId: 247778691
* Add support for using llvm::dyn_cast/cast/isa for operation casts and ↵River Riddle2019-05-202-7/+7
| | | | | | | | replace usages of Operation::dyn_cast with llvm::dyn_cast. -- PiperOrigin-RevId: 247778391
* Fix unused variable warning in the Toy tutorial (NFC)Mehdi Amini2019-05-101-1/+0
| | | | | | -- PiperOrigin-RevId: 247672377
* Add explicit friendship with Operation to each derived op class to ↵River Riddle2019-05-061-0/+10
| | | | | | | | ensure access to the inherited protected constructor of `Op`. Some compiler versions have different rules for the visibility of inherited constructors. -- PiperOrigin-RevId: 246661686
* Expose `setupTargetTriple` as a public static method on ExecutionEngineMehdi Amini2019-04-111-0/+1
| | | | | | | | | | This allows client to be able to reuse the same logic to setup a module for the ExecutionEngine without instanciating one. One use case is running the optimization pipeline but not JIT-ing. -- PiperOrigin-RevId: 242614380
* Fix Toy cmake build: add missing includesMehdi Amini2019-04-081-0/+3
| | | | | | -- PiperOrigin-RevId: 242609231
* Toy tutorial Chapter 5: Lowering to Linalg and LLVMMehdi Amini2019-04-0816-0/+4217
-- PiperOrigin-RevId: 242606796
OpenPOWER on IntegriCloud