summaryrefslogtreecommitdiffstats
path: root/mlir/test/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Migrate pattern symbol binding tests to use TestDialectLei Zhang2019-07-311-0/+42
| | | | PiperOrigin-RevId: 261045611
* Fix support for auxiliary ops in declarative rewrite rulesLei Zhang2019-07-311-8/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We allow to generate more ops than what are needed for replacing the matched root op. Only the last N static values generated are used as replacement; the others serve as auxiliary ops/values for building the replacement. With the introduction of multi-result op support, an op, if used as a whole, may be used to replace multiple static values of the matched root op. We need to consider this when calculating the result range an generated op is to replace. For example, we can have the following pattern: ```tblgen def : Pattern<(ThreeResultOp ...), [(OneResultOp ...), (OneResultOp ...), (OneResultOp ...)]>; // Two op to replace all three results def : Pattern<(ThreeResultOp ...), [(TwoResultOp ...), (OneResultOp ...)]>; // One op to replace all three results def : Pat<(ThreeResultOp ...), (ThreeResultOp ...)>; def : Pattern<(ThreeResultOp ...), [(AuxiliaryOp ...), (ThreeResultOp ...)]>; ``` PiperOrigin-RevId: 261017235
* RewriterGen: properly handle zero-result opsAlex Zinenko2019-07-301-0/+10
| | | | | | | | | RewriterGen was emitting invalid C++ code if the pattern required to create a zero-result operation due to the absence of a special case that would avoid generating a spurious comma. Handle this case. Also add rewriter tests for zero-argument operations. PiperOrigin-RevId: 260576998
* Fix SingleBlockImplicitTerminator traits to catch empty blocksMehdi Amini2019-07-301-0/+8
| | | | | | | | | | The code was written with the assumption that on failure an error would be issued by another verifier. However verification is stopping on the first failure which lead to an empty output. Instead we make sure an error is displayed. Also add tests in the test dialect for this trait. PiperOrigin-RevId: 260541290
* Add a `HasParent` operation trait to enforce a specific parent on an ↵Mehdi Amini2019-07-301-0/+4
| | | | | | operation (NFC) PiperOrigin-RevId: 260532592
* Support referencing a single value generated by a matched multi-result opLei Zhang2019-07-261-1/+11
| | | | | | | | It's quite common that we want to put further constraints on the matched multi-result op's specific results. This CL enables referencing symbols bound to source op with the `__N` syntax. PiperOrigin-RevId: 260122401
* Add support for an analysis mode to DialectConversion.River Riddle2019-07-251-5/+42
| | | | | | | | This mode analyzes which operations are legalizable to the given target if a conversion were to be applied, i.e. no rewrites are ever performed even on success. This mode is useful for device partitioning or other utilities that may want to analyze the effect of conversion to different targets before performing it. The analysis method currently just fills a provided set with the operations that were found to be legalizable. This can be extended in the future to capture more information as necessary. PiperOrigin-RevId: 259987105
* Cleanup slicing test.Nicolas Vasilache2019-07-241-0/+4
| | | | | | Remove hardcoded SSA names and make use of CHECK-LABEL directives. PiperOrigin-RevId: 259767803
* ODS: support UnitAttr in Operation definitionsAlex Zinenko2019-07-231-0/+11
| | | | | | | | | | | | | | | A recent commit introduced UnitAttr into the ODS but did not include the support for using UnitAttrs in operation definitions (only patterns were supported). Extend the ODS definition of UnitAttr to be usable in operation definition by providing a trivial builder and an accessor that returns "true" if the unit attribute is present since the attribute presence itself has meaning. Additionally, test that unit attributes are effectively rewritten in patterns in addition to the already available FileCheck tests of the generated rewriter code. PiperOrigin-RevId: 259560653
* Introduce parser library method to parse list of region argumentsUday Bondhugula2019-07-222-0/+34
| | | | | | | | | | | | | | | | | - introduce parseRegionArgumentList (similar to parseOperandList) to parse a list of region arguments with a delimiter - allows defining custom parse for op's with multiple/variadic number of region arguments - use this on the gpu.launch op (although the latter has a fixed number of region arguments) - add a test dialect op to test region argument list parsing (with the no delimiter case) Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#40 PiperOrigin-RevId: 259442536
* Refactor LoopParametricTiling as a test pass - NFCNicolas Vasilache2019-07-222-0/+72
| | | | | | This CL moves LoopParametricTiling into test/lib as a pass for purely testing purposes. PiperOrigin-RevId: 259300264
* Refactor region type signature conversion to be explicit via patterns.River Riddle2019-07-201-3/+6
| | | | | | This cl enforces that the conversion of the type signatures for regions, and thus their entry blocks, is handled via ConversionPatterns. A new hook 'applySignatureConversion' is added to the ConversionPatternRewriter to perform the desired conversion on a region. This also means that the handling of rewriting the signature of a FuncOp is moved to a pattern. A default implementation is provided via 'mlir::populateFuncOpTypeConversionPattern'. This removes the hacky implicit 'dynamically legal' status of FuncOp that was present previously, and leaves it up to the user to decide when/how to convert the signature of a function. PiperOrigin-RevId: 259161999
* Merge TypeUtilities library into the IR libraryAlex Zinenko2019-07-202-3/+3
| | | | | | | | | | The TypeUtilities.{cpp,h}, currently living in {lib,include/mlir}/Support, do not belong to the Support library. Instead, they form a separate utility library that depends on the IR library. The operations it provides relate to standard types (tensors, memrefs) as well as to operation manipulation, making them a better fit for the main IR library. PiperOrigin-RevId: 259108314
* Add missing MLIRDialect dependency for MLIRDialectLei Zhang2019-07-191-0/+1
| | | | | | | Tests for the Broadcastable trait was added in a previous CL, which makes MLIRDialect depend on MLIRDialect now. PiperOrigin-RevId: 258967332
* Utility function to map a loop on a parametric grid of virtual processorsNicolas Vasilache2019-07-192-0/+67
| | | | | | | | | | | | | | | | | | | | | | This CL introduces a simple loop utility function which rewrites the bounds and step of a loop so as to become mappable on a regular grid of processors whose identifiers are given by SSA values. A corresponding unit test is added. For example, using CUDA terminology, and assuming a 2-d grid with processorIds = [blockIdx.x, threadIdx.x] and numProcessors = [gridDim.x, blockDim.x], the loop: ``` loop.for %i = %lb to %ub step %step { ... } ``` is rewritten into a version resembling the following pseudo-IR: ``` loop.for %i = %lb + threadIdx.x + blockIdx.x * blockDim.x to %ub step %gridDim.x * blockDim.x { ... } ``` PiperOrigin-RevId: 258945942
* Add support for providing a legality callback for dynamic legality in ↵River Riddle2019-07-191-14/+10
| | | | | | | | | | | | | | | | | | DialectConversion. This allows for providing specific handling for dynamically legal operations/dialects without overriding the general 'isDynamicallyLegal' hook. This also means that a derived ConversionTarget class need not always be defined when some operations are dynamically legal. Example usage: ConversionTarget target(...); target.addDynamicallyLegalOp<ReturnOp>([](ReturnOp op) { return ... }; target.addDynamicallyLegalDialect<StandardOpsDialect>([](Operation *op) { return ... }; PiperOrigin-RevId: 258884753
* NFC: Expose a ConversionPatternRewriter for use with ConversionPatterns.River Riddle2019-07-191-8/+12
| | | | | | This specific PatternRewriter will allow for exposing hooks in the future that are only useful for the conversion framework, e.g. type conversions. PiperOrigin-RevId: 258818122
* Refactor the conversion of block argument types in DialectConversion.River Riddle2019-07-192-6/+30
| | | | | | | | This cl begins a large refactoring over how signature types are converted in the DialectConversion infrastructure. The signatures of blocks are now converted on-demand when an operation held by that block is being converted. This allows for handling the case where a region is created as part of a pattern, something that wasn't possible previously. This cl also generalizes the region signature conversion used by FuncOp to work on any region of any operation. This generalization allows for removing the 'apply*Conversion' functions that were specific to FuncOp/ModuleOp. The implementation currently uses a new hook on TypeConverter, 'convertRegionSignature', but this should ideally be removed in favor of using Patterns. That depends on adding support to the PatternRewriter used by ConversionPattern to allow applying signature conversions to regions, which should be coming in a followup. PiperOrigin-RevId: 258645733
* Add tests for broadcastable traitSmit Hinsu2019-07-192-0/+6
| | | | PiperOrigin-RevId: 258637509
* Add support for explicitly marking dialects and operations as illegal.River Riddle2019-07-192-0/+2
| | | | | | | | This explicit tag is useful is several ways: *) This simplifies how to mark sub sections of a dialect as explicitly unsupported, e.g. my target supports all operations in the foo dialect except for these select few. This is useful for partial lowerings between dialects. *) Partial conversions will now verify that operations that were explicitly marked as illegal must be converted. This provides some guarantee that the operations that need to be lowered by a specific pass will be. PiperOrigin-RevId: 258582879
* Refactor DialectConversion to support different conversion modes.River Riddle2019-07-161-2/+2
| | | | | | | | | | | Users generally want several different modes of conversion. This cl refactors DialectConversion to provide two: * Partial (applyPartialConversion) - This mode allows for illegal operations to exist in the IR, and does not fail if an operation fails to be legalized. * Full (applyFullConversion) - This mode fails if any operation is not properly legalized to the conversion target. This allows for ensuring that the IR after a conversion only contains operations legal for the target. PiperOrigin-RevId: 258412243
* Add a TypeIsPred.Jacques Pienaar2019-07-161-0/+9
| | | | | | | | Mostly one would use the type specification directly on the operand, but for cases where the type of the operand depends on other operand types, `TypeIs` attribute can be used to construct verification methods. PiperOrigin-RevId: 258411758
* Fix a bug in DialectConversion when using RewritePattern.River Riddle2019-07-161-0/+5
| | | | | | When using a RewritePattern and replacing an operation with an existing value, that value may have already been replaced by something else. This cl ensures that only the final value is used when applying rewrites. PiperOrigin-RevId: 258058488
* NFC: Rename Function to FuncOp.River Riddle2019-07-101-1/+1
| | | | PiperOrigin-RevId: 257293379
* Add missing override.Jacques Pienaar2019-07-081-1/+2
| | | | PiperOrigin-RevId: 257024265
* Migrate NativeCodeCall and AllAttrConstraintsOf tests to use TestDialectLei Zhang2019-07-052-0/+58
| | | | PiperOrigin-RevId: 256685260
* Migrate pattern attribute matching tests to use TestDialectLei Zhang2019-07-051-26/+48
| | | | | | | This CL also reorders op definitions and tests a bit to make them group more logically. PiperOrigin-RevId: 256682105
* [TableGen] Support creating multi-result ops in result patternsLei Zhang2019-07-031-0/+74
| | | | | | | | | | This CL introduces a new syntax for creating multi-result ops and access their results in result patterns. Specifically, if a multi-result op is unbound or bound to a name without a trailing `__N` suffix, it will act as a value pack and expand to all its values. If a multi-result op is bound to a symbol with `__N` suffix, only the N-th result will be extracted and used. PiperOrigin-RevId: 256465208
* [ODS] NFC: Rename EnumAttr to StrEnumAttr to be consistent with IntEnumAttrLei Zhang2019-07-021-6/+6
| | | | PiperOrigin-RevId: 256169019
* NFC: Refactor Function to be value typed.River Riddle2019-07-011-8/+8
| | | | | | 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
* [ODS] Introduce IntEnumAttrLei Zhang2019-07-011-0/+39
| | | | | | | | | | | | | | | | | | | In ODS, right now we use StringAttrs to emulate enum attributes. It is suboptimal if the op actually can and wants to store the enum as a single integer value; we are paying extra cost on storing and comparing the attribute value. This CL introduces a new enum attribute subclass that are backed by IntegerAttr. The downside with IntegerAttr-backed enum attributes is that the assembly form now uses integer values, which is less obvious than the StringAttr-backed ones. However, that can be remedied by defining custom assembly form with the help of the conversion utility functions generated via EnumsGen. Choices are given to the dialect writers to decide which one to use for their enum attributes. PiperOrigin-RevId: 255935542
* Refactor DialectConversion to use 'materializeConversion' when a type ↵River Riddle2019-06-282-1/+17
| | | | | | | | 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
* Respect the user provided type when parsing StringAttr.River Riddle2019-06-272-0/+11
| | | | PiperOrigin-RevId: 255532918
* Move the emitError/Warning/Remark utility methods out of MLIRContext and ↵River Riddle2019-06-251-1/+1
| | | | | | | | 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
* Update the OperationFolder to find a valid insertion point when ↵River Riddle2019-06-251-4/+2
| | | | | | | | materializing constants. The OperationFolder currently just inserts into the entry block of a Function, but regions may be isolated above, i.e. explicit capture only, and blindly inserting constants may break the invariants of these regions. PiperOrigin-RevId: 254987796
* Split test-specific passes out of mlir-optNicolas Vasilache2019-06-2411-0/+1095
Instead put their impl in test/lib and link them into mlir-test-opt PiperOrigin-RevId: 254837439
OpenPOWER on IntegriCloud