summaryrefslogtreecommitdiffstats
path: root/mlir/test/EDSC/builder-api-test.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [mlir] NFC: Rename index_t to index_typeRainer Orth2020-03-061-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | mlir currently fails to build on Solaris: /vol/llvm/src/llvm-project/dist/mlir/lib/Conversion/VectorToLoops/ConvertVectorToLoops.cpp:78:20: error: reference to 'index_t' is ambiguous IndexHandle zero(index_t(0)), one(index_t(1)); ^ /usr/include/sys/types.h:103:16: note: candidate found by name lookup is 'index_t' typedef short index_t; ^ /vol/llvm/src/llvm-project/dist/mlir/include/mlir/EDSC/Builders.h:27:8: note: candidate found by name lookup is 'mlir::edsc::index_t' struct index_t { ^ and many more. Given that POSIX reserves all identifiers ending in `_t` 2.2.2 The Name Space <https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html>, it seems quite unwise to use such identifiers in user code, even more so without a distinguished prefix. The following patch fixes this by renaming `index_t` to `index_type`. cases. Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`. Differential Revision: https://reviews.llvm.org/D72619 (cherry picked from commit 002ec79f979b9da9dedafe7ea036e00c90a9fbb7)
* [mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid ↵River Riddle2020-01-131-49/+49
| | | | | | | | | | conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
* [mlir][Linalg] Update ReshapeOp::build to be more idiomaticNicolas Vasilache2020-01-131-0/+27
| | | | | | | | | | | | | | Summary: This diff makes it easier to create a `linalg.reshape` op and adds an EDSC builder api test to exercise the new builders. Reviewers: ftynse, jpienaar Subscribers: mehdi_amini, rriddle, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72580
* Add zero_extendi and sign_extendi to intrinsic namespacePruthvi2020-01-131-0/+26
| | | | | | | | Summary: - update zero_extendi and sign_extendi in edsc/intrinsic namespace - Builder API test for zero_extendi and sign_extendi Differential Revision: https://reviews.llvm.org/D72298
* [mlir] fix test failure in EDSC/builder-api-testHiroshi Inoue2020-01-091-3/+4
| | | | | | | | This patch fixes a test failure on a non-intel (PowerPC64) box. The two affine.load are independent and hence llvm may reorder them. The CHECK lines are modified for supporting reordered case. Differential Revision: https://reviews.llvm.org/D72435
* NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.River Riddle2019-12-231-1/+1
| | | | | | ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-231-13/+4
| | | | PiperOrigin-RevId: 286906740
* NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to ↵River Riddle2019-12-221-2/+2
| | | | | | | | | | 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
* Add integer bit-shift operations to the standard dialect.Manuel Freiberger2019-12-221-2/+2
| | | | | | | | | | | | | | | | | | | Rename the 'shlis' operation in the standard dialect to 'shift_left'. Add tests for this operation (these have been missing so far) and add a lowering to the 'shl' operation in the LLVM dialect. Add also 'shift_right_signed' (lowered to LLVM's 'ashr') and 'shift_right_unsigned' (lowered to 'lshr'). The original plan was to name these operations 'shift.left', 'shift.right.signed' and 'shift.right.unsigned'. This works if the operations are prefixed with 'std.' in MLIR assembly. Unfortunately during import the short form is ambigous with operations from a hypothetical 'shift' dialect. The best solution seems to omit dots in standard operations for now. Closes tensorflow/mlir#226 PiperOrigin-RevId: 286803388
* Add edsc::ops for pointwise, conv and dilated_convNicolas Vasilache2019-12-161-2/+111
| | | | | | | | | This CL adds more Linalg EDSC ops and tests to support building pointwise operations along with conv and dilated_conv. This also fixes a bug in the existing linalg_matmul EDSC and beefs up the test. The current set of ops is already enough to build an interesting, albeit simple, model used internally. PiperOrigin-RevId: 285838012
* Apply a level of sugaring to the linalg.generic EDSC - NFCNicolas Vasilache2019-12-131-18/+1
| | | | | | Make the declarative C++ builder API simpler to use so we can start chaining these ops together. PiperOrigin-RevId: 285496266
* Add a layer of EDSC for linalg.GenericOpNicolas Vasilache2019-12-131-0/+46
| | | | | | | | This will be evolved into a simple programming model for custom ops and custom layers in followup CLs. This CL also deletes the obsolete tablegen's reference-impl.td that was using EDSCs. PiperOrigin-RevId: 285459545
* Automated rollback of commit 575405f4d6762830c1c4520569de4e4ed3c8eed5Nicolas Vasilache2019-10-181-8/+32
| | | | PiperOrigin-RevId: 275461067
* NFC: Remove trivial builder get methods.River Riddle2019-10-171-1/+1
| | | | | | These don't add any value, and some are even more restrictive than the respective static 'get' method. PiperOrigin-RevId: 275391240
* Automated rollback of commit b65c8bb5d6ab418bb3fcd0302aee19d3615d90f1River Riddle2019-10-171-32/+8
| | | | PiperOrigin-RevId: 275370861
* Add EDSC support for loop.for operationsNicolas Vasilache2019-10-171-8/+32
| | | | | | | This CL adds support for loop.for operations in EDSC and adds a test. This will be used in a followup commit to implement lowering of vector_transfer ops so that it works more generally and is not subject to affine constraints. PiperOrigin-RevId: 275349796
* Rename LoopNestBuilder to AffineLoopNestBuilder - NFCNicolas Vasilache2019-10-171-9/+9
| | | | PiperOrigin-RevId: 275310747
* Add custom builder for AffineIfOpNagy Mostafa2019-09-061-0/+36
| | | | | | | Closes tensorflow/mlir#109 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/109 from nmostafa:nmostafa/AffineIfOp 7dbf2115f0092ffab26381ea8704aa05a0253971 PiperOrigin-RevId: 267633077
* Extend map canonicalization to propagate constant operandsUday Bondhugula2019-08-291-6/+6
| | | | | | | | | | | | | | | | | | | - extend canonicalizeMapAndOperands to propagate constant operands into the map's expressions (and thus drop those operands). - canonicalizeMapAndOperands previously only dropped duplicate and unused operands; however, operands that were constants were retained. This change makes IR maps/expressions generated by various utilities/passes even simpler; also makes some of the test checks more accurate and simpler -- for eg., 0' instead of symbol(%{{.*}}). Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#107 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/107 from bondhugula:canonicalize-maps c889a51486d14fbf7db489f224f881e7e1ff7d72 PiperOrigin-RevId: 266085289
* NFC: Move AffineOps dialect to the Dialect sub-directory.River Riddle2019-08-201-1/+1
| | | | PiperOrigin-RevId: 264482571
* Fix build of affine load/store with empty mapDiego Caballero2019-08-201-0/+32
| | | | | | | | | | | | | | | tensorflow/mlir#58 fixed and exercised verification of load/store ops using empty affine maps. Unfortunately, it didn't exercise the creation of them. This PR addresses that aspect. It removes the assumption of AffineMap having at least one result and stores a pointer to MLIRContext as member of AffineMap. * Add empty map support to affine.store + test * Move MLIRContext to AffineMapStorage Closes tensorflow/mlir#74 PiperOrigin-RevId: 264416260
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-191-1/+1
| | | | PiperOrigin-RevId: 264193915
* Add support for floating-point comparison 'fcmp' to the LLVM dialect.Nagy Mostafa2019-08-081-1/+76
| | | | | | | | This adds support for fcmp to the LLVM dialect and adds any necessary lowerings, as well as support for EDSCs. Closes tensorflow/mlir#69 PiperOrigin-RevId: 262475255
* Add StdIndexedValue to EDSC helpersDiego Caballero2019-08-021-0/+36
| | | | | | | | | Add StdIndexedValue to EDSC helper so that we can use it to generated std.load and std.store in EDSC. Closes tensorflow/mlir#59 PiperOrigin-RevId: 261324965
* EDSC: use affine.load/store instead of std.load/storeAlex Zinenko2019-07-121-16/+16
| | | | | | | | | | | Standard load and store operations are evolving to be separated from the Affine constructs. Special affine.load/store have been introduced to uphold the restrictions of the Affine control flow constructs on their operands. EDSC-produced loads and stores were originally intended to uphold those restrictions as well so they should use affine.load/store instead of std.load/store. PiperOrigin-RevId: 257443307
* 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: Rename Function to FuncOp.River Riddle2019-07-101-5/+5
| | | | PiperOrigin-RevId: 257293379
* Constrain regex to avoid ordering issues.Jacques Pienaar2019-07-091-2/+2
| | | | PiperOrigin-RevId: 257257173
* Standardize the value numbering in the AsmPrinter.River Riddle2019-07-091-88/+88
| | | | | | Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
* Globally change load/store/dma_start/dma_wait operations over to ↵Andy Davis2019-07-031-12/+20
| | | | | | | | | | | affine.load/store/dma_start/dma_wait. In most places, this is just a name change (with the exception of affine.dma_start swapping the operand positions of its tag memref and num_elements operands). Significant code changes occur here: *) Vectorization: LoopAnalysis.cpp, Vectorize.cpp *) Affine Transforms: Transforms/Utils/Utils.cpp PiperOrigin-RevId: 256395088
* NFC: Refactor Module to be value typed.River Riddle2019-07-021-2/+2
| | | | | | 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-011-70/+80
| | | | | | 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
* Change the attribute dictionary syntax to separate name and value with '='.River Riddle2019-06-251-3/+3
| | | | | | | | | | | The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
* NFC: Rename FuncBuilder to OpBuilder and refactor to take a top level region ↵River Riddle2019-06-091-13/+13
| | | | | | instead of a function. PiperOrigin-RevId: 251563898
* Make EDSC builder test more robust to the order of evaluationAlex Zinenko2019-06-011-33/+33
| | | | | | | | | | | | | | EDSC builder test uses FileCheck to match the IR produced by EDSC in the textual order. For mathematical operations, EDSC relies on overloaded operators. Since they are essentially function calls, the order of evaluation of their operands is unspecified and differs between compilers. Do not rely on a specific order of operands and just check they are all emitted before the last operation. Give names to matched SSA values in order to make sure the right operands are used in relevant places. -- PiperOrigin-RevId: 249494995
* Use lambdas for nesting edsc constructs.Nicolas Vasilache2019-05-201-66/+58
| | | | | | | | | | | 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
* Use FileCheck to test SDBMAlex Zinenko2019-05-201-1/+1
| | | | | | | | | | | | | SDBM has an output format representing the unterlying matrix and stripe expressions. Move the SDBM tests from unit testing framework to FileCheck-based tests, printing them to the standard output and using FileCheck to test the output. Tests that check the API proper (e.g. that SDBM expressions have a specific subtype) and that rely on non-syntatic properties (equality of the set of constraints) are not ported. -- PiperOrigin-RevId: 249006055
* Add support for saving and restoring the insertion point of a ↵River Riddle2019-05-201-14/+27
| | | | | | | | FuncBuilder. This also updates the edsc::ScopedContext to use a single builder that saves/restores insertion points. This is necessary for using edscs within RewritePatterns. -- PiperOrigin-RevId: 248812645
* Enable EDSC API test running through litAlex Zinenko2019-05-201-1/+1
| | | | | | | | | | | EDSC subsystem contains an API test which is a .cpp file calling the API in question and producing IR. This IR is further checked using FileCheck and should plug into lit. Provide a CMakeLists.txt to build the test and modify the lit configuration to process the source file. -- PiperOrigin-RevId: 248794443
* Cleanup SuperVectorization dialect printing and parsing.Nicolas Vasilache2019-03-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the read side, ``` %3 = vector_transfer_read %arg0, %i2, %i1, %i0 {permutation_map: (d0, d1, d2)->(d2, d0)} : (memref<?x?x?xf32>, index, index, index) -> vector<32x256xf32> ``` becomes: ``` %3 = vector_transfer_read %arg0[%i2, %i1, %i0] {permutation_map: (d0, d1, d2)->(d2, d0)} : memref<?x?x?xf32>, vector<32x256xf32> ``` On the write side, ``` vector_transfer_write %0, %arg0, %c3, %c3 {permutation_map: (d0, d1)->(d0)} : vector<128xf32>, memref<?x?xf32>, index, index ``` becomes ``` vector_transfer_write %0, %arg0[%c3, %c3] {permutation_map: (d0, d1)->(d0)} : vector<128xf32>, memref<?x?xf32> ``` Documentation will be cleaned up in a followup commit that also extracts a proper .md from the top of the file comments. PiperOrigin-RevId: 241021879
* Change the muli-return syntax for operations. The name of the operation ↵River Riddle2019-03-291-1/+1
| | | | | | | | | | | | | | | result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
* Replace remaining usages of the Instruction class with Operation.River Riddle2019-03-291-8/+8
| | | | PiperOrigin-RevId: 240777521
* Give the Vectorize pass a virtualVectorSize argument.Nicolas Vasilache2019-03-291-0/+52
| | | | | | | This CL allows vectorization to be called and configured in other ways than just via command line arguments. This allows triggering vectorization programmatically. PiperOrigin-RevId: 240638208
* Use dereference instead of implicit conversion for IndexedValue to Value*.Jacques Pienaar2019-03-291-1/+1
| | | | | | Avoids ambiguous constructor error on some compilers. PiperOrigin-RevId: 240606838
* Port api-test::tile_2d to the edsc::Builder APINicolas Vasilache2019-03-291-0/+70
| | | | | | The AST-based EDSCs implementation will be retired soon, this test was missing from the builders API. PiperOrigin-RevId: 240547453
* Replace usages of Instruction with Operation in the /IR directory.River Riddle2019-03-291-2/+2
| | | | | | This is step 2/N to renaming Instruction to Operation. PiperOrigin-RevId: 240459216
* Add an IndexedValue::operator Value*Nicolas Vasilache2019-03-291-0/+33
| | | | | | This avoids the need to explicitly convert to a ValueHandle when using an Indexed where a Value* is expected. PiperOrigin-RevId: 240371014
* NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and ↵River Riddle2019-03-291-10/+10
| | | | | | set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
* Cleanup ValueHandleArrayNicolas Vasilache2019-03-291-5/+5
| | | | | | | | | We just need a way to unpack ArrayRef<ValueHandle> to ArrayRef<Value*>. No need to expose this to the user. This reduces the cognitive overhead for the tutorial. PiperOrigin-RevId: 240037425
* Support composition of symbols in AffineApplyOpNicolas Vasilache2019-03-291-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | This CL revisits the composition of AffineApplyOp for the special case where a symbol itself comes from an AffineApplyOp. This is achieved by rewriting such symbols into dims to allow composition to occur mathematically. The implementation is also refactored to improve readability. Rationale for locally rewriting symbols as dims: ================================================ The mathematical composition of AffineMap must always concatenate symbols because it does not have enough information to do otherwise. For example, composing `(d0)[s0] -> (d0 + s0)` with itself must produce `(d0)[s0, s1] -> (d0 + s0 + s1)`. The result is only equivalent to `(d0)[s0] -> (d0 + 2 * s0)` when applied to the same mlir::Value* for both s0 and s1. As a consequence mathematical composition of AffineMap always concatenates symbols. When AffineMaps are used in AffineApplyOp however, they may specify composition via symbols, which is ambiguous mathematically. This corner case is handled by locally rewriting such symbols that come from AffineApplyOp into dims and composing through dims. PiperOrigin-RevId: 239791597
OpenPOWER on IntegriCloud