summaryrefslogtreecommitdiffstats
path: root/mlir/test/Target
Commit message (Collapse)AuthorAgeFilesLines
...
* Refactor FunctionAttr to hold the internal function reference by name ↵River Riddle2019-06-011-1/+1
| | | | | | | | | | | | | | | | instead of pointer. The one downside to this is that the function reference held by a FunctionAttr needs to be explicitly looked up from the parent module. This provides several benefits though: * There is no longer a need to explicitly remap function attrs. - This removes a potentially expensive call from the destructor of Function. - This will enable some interprocedural transformations to now run intraprocedurally. - This wasn't scalable and forces dialect defined attributes to override a virtual function. * Replacing a function is now a trivial operation. * This is a necessary first step to representing functions as operations. -- PiperOrigin-RevId: 249510802
* Add transformation of the NVVM dialect to an LLVM module. Only handlesStephan Herhut2019-05-061-0/+29
| | | | | | | | the generation of intrinsics out of NVVM index ops for now. -- PiperOrigin-RevId: 245933152
* Add conversion of StandardOps and, or and xor to LLVM dialect.Stephan Herhut2019-04-111-0/+13
| | | | | | -- PiperOrigin-RevId: 242831203
* Introduce std.varargs attribute to mark variadic arguments functionsMehdi Amini2019-04-071-0/+4
| | | | | | | | | | | This is only teaching the LLVM converter to propagate the attribute onto the function type. MLIR will not recognize this arguments, so it would only be useful when calling for example `printf` with the same arguments across a module. Since varargs is part of the ABI lowering, this is not NFC. -- PiperOrigin-RevId: 242382427
* Change the asmprinter to use pretty syntax for dialect types when it can,Chris Lattner2019-04-071-230/+230
| | | | | | | | | | | | making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
* Introduce custom format for the LLVM IR DialectAlex Zinenko2019-04-021-327/+327
| | | | | | | | | | | Historically, the LLVM IR dialect has been using the generic form of MLIR operation syntax. It is verbose and often redundant. Introduce the custom printing and parsing for all existing operations in the LLVM IR dialect. Update the relevant documentation and tests. -- PiperOrigin-RevId: 241617393
* Remove "<label>" from the llvm basic block CHECK names.River Riddle2019-03-291-30/+30
| | | | PiperOrigin-RevId: 239898185
* Using llvm.noalias attribute when generating LLVMIR.Dimitrios Vytiniotis2019-03-291-0/+5
| | | | PiperOrigin-RevId: 237063104
* LLVM IR Dialect: unify call and call0 operationsAlex Zinenko2019-03-291-13/+13
| | | | | | | | | | | | | | When the LLVM IR dialect was implemented, TableGen operation definition scheme did not support operations with variadic results. Therefore, the `call` instruction was split into `call` and `call0` for the single- and zero-result calls (LLVM does not support multi-result operations). Unify `call` and `call0` using the recently added TableGen support for operations with Variadic results. Explicitly verify that the new operation has 0 or 1 results. As a side effect, this change enables clean-ups in the conversion to the LLVM IR dialect that no longer needs to rely on wrapped LLVM IR void types when constructing zero-result calls. PiperOrigin-RevId: 236119197
* LLVM IR dialect and translation: support conditional branches with argumentsAlex Zinenko2019-03-291-0/+21
| | | | | | | | | | | | | | | | | Since the goal of the LLVM IR dialect is to reflect LLVM IR in MLIR, the dialect and the conversion procedure must account for the differences betweeen block arguments and LLVM IR PHI nodes. In particular, LLVM IR disallows PHI nodes with different values coming from the same source. Therefore, the LLVM IR dialect now disallows `cond_br` operations that have identical successors accepting arguments, which would lead to invalid PHI nodes. The conversion process resolves the potential PHI source ambiguity by injecting dummy blocks if the same block is used more than once as a successor in an instruction. These dummy blocks branch unconditionally to the original successors, pass them the original operands (available in the dummy block because it is dominated by the original block) and are used instead of them in the original terminator operation. PiperOrigin-RevId: 235682798
* Lower standard DivF and RemF operations to the LLVM IR dialectAlex Zinenko2019-03-291-0/+10
| | | | | | | | | | Add support for lowering DivF and RemF to LLVM::FDiv and LLMV::FRem respectively. The lowering is a trivial one-to-one transformation. The corresponding operations already existed in the LLVM IR dialect and can be lowered to the LLVM IR proper. Add the necessary tests for scalar and vector forms. PiperOrigin-RevId: 234984608
* LLVM dialect conversion and target: support indirect callsAlex Zinenko2019-03-291-0/+22
| | | | | | | | | | | | | | | | | | | | Add support for converting MLIR `call_indirect` instructions to the LLVM IR dialect. In LLVM IR, the same instruction is used for direct and indirect calls. In the dialect, we have `llvm.call` and `llvm.call0` to work around the absence of the void type in MLIR. For direct calls, the callee is stored as instruction attribute. Use the same pair of instructions for indirect calls by omitting the callee attribute. In the MLIR to LLVM IR translator, check the presence of attribute to decide whether to construct a direct or an indirect call using different LLVM IR Builder functions. Add support for converting constants of function type to the LLVM IR dialect and for translating them to the LLVM IR proper. The `llvm.constant` operation works similarly to other types: its attribute has MLIR function type but the value it produces has LLVM IR function type wrapped in the dialect type. While lowering, look up the pointer to the converted function in the corresponding mapping. PiperOrigin-RevId: 234132351
* Reimplement LLVM IR translation to use the MLIR LLVM IR dialectAlex Zinenko2019-03-291-277/+372
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
* LLVM IR lowering: support integer division and remainder operationsAlex Zinenko2019-03-291-7/+25
| | | | | | | | | | These operations trivially map to LLVM IR counterparts for operands of scalar and (one-dimensional) vector type. Multi-dimensional vector and tensor type operands would fail type conversion before the operation conversion takes place. Add tests for scalar and vector cases. Also add a test for vector `select` instruction for consistency with other tests. PiperOrigin-RevId: 228077564
* Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead.Chris Lattner2019-03-291-31/+31
| | | | | | | | | | | | | The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
* LLVM IR Lowering: support "select"Alex Zinenko2019-03-291-2/+6
| | | | | | | This commit adds support for the "select" operation that lowers directly into its LLVM IR counterpart. A simple test is included. PiperOrigin-RevId: 227527893
* Have the asmprinter take advantage of the new capabilities of the asmparser, byChris Lattner2019-03-291-4/+4
| | | | | | | | | | printing the entry block in a CFG function's argument line. Since I'm touching all of the testcases anyway, change the argument list from printing as "%arg : type" to "%arg: type" which is more consistent with bb arguments. In addition to being more consistent, this is a much nicer look for cfg functions. PiperOrigin-RevId: 227240069
* Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIRChris Lattner2019-03-291-142/+142
| | | | | | syntax. PiperOrigin-RevId: 227234174
* Tidy up references to "basic blocks" that should refer to blocks now. NFC.Chris Lattner2019-03-291-1/+1
| | | | PiperOrigin-RevId: 227196077
* LLVM IR lowering: support SubIOp and SubFOpAlex Zinenko2019-03-291-0/+10
| | | | | | | | The binary subtraction operations were not supported by the lowering because they were not essential for the testing flow. Add support for these operations. PiperOrigin-RevId: 226941463
* LLVM IR lowering: support 1D vector operationsAlex Zinenko2019-03-291-0/+11
| | | | | | | | | | | | | | | | Introduce initial support for 1D vector operations. LLVM does not support higher-dimensional vectors so the caller must make sure they don't appear in the input MLIR. Handle the presence of higher-dimensional vectors by failing gracefully. Introduce the type conversion for 1D vector types and hook it up with the rest of the type convresion system. Support "splat" constants for vector types. As a side effect, this refactors constant operation emission by separating out scalar integer constants into a separate case and by extracting out the helper function for scalar float construction. Existing binary operations apply to vectors transparently. PiperOrigin-RevId: 225172349
* LLVM IR Lowering: support multi-value returns.Alex Zinenko2019-03-291-0/+38
| | | | | | | | | Unlike MLIR, LLVM IR does not support functions that return multiple values. Simulate this by packing values into the LLVM structure type in the same order as they appear in the MLIR return. If the function returns only a single value, return it directly without packing. PiperOrigin-RevId: 223964886
* LLVM IR lowering: support 'dim' operation.Alex Zinenko2019-03-291-0/+23
| | | | | | | | | | Add support for translating 'dim' opreation on MemRefs to LLVM IR. For a static size, this operation merely defines an LLVM IR constant value that may not appear in the output IR if not used (and had not been removed before by DCE). For a dynamic size, this operation is translated into an access to the MemRef descriptor that contains the dynamic size. PiperOrigin-RevId: 223160774
* LLVM IR lowering: support simple MemRef typesAlex Zinenko2019-03-291-0/+230
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce initial support for MemRef types, including type conversion, allocation and deallocation, read and write element-wise access, passing MemRefs to and returning from functions. Affine map compositions and non-default memory spaces are NOT YET supported. Lowered code needs to handle potentially dynamic sizes of the MemRef. To do so, it replaces a MemRef-typed value with a special MemRef descriptor that carries the data and the dynamic sizes together. A MemRef type is converted to LLVM's first-class structure type with the first element being the pointer to the data buffer with data layed out linearly, followed by as many integer-typed elements as MemRef has dynamic sizes. The type of these elements is that of MLIR index lowered to LLVM. For example, `memref<?x42x?xf32>` is converted to `{ f32*, i64, i64 }` provided `index` is lowered to `i64`. While it is possible to convert MemRefs with fully static sizes to simple pointers to their elemental types, we opted for consistency and convert them to the single-element structure. This makes the conversion code simpler and the calling convention of the generated LLVM IR functions consistent. Loads from and stores to a MemRef element are lowered to a sequence of LLVM instructions that, first, computes the linearized index of the element in the data buffer using the access indices and combining the static sizes with the dynamic sizes stored in the descriptor, and then loads from or stores to the buffer element indexed by the linearized subscript. While some of the index computations may be redundant (i.e., consecutive load and store to the same location in the same scope could reuse the linearized index), we emit them for every operation. A subsequent optimization pass may eliminate them if necessary. MemRef allocation and deallocation is performed using external functions `__mlir_alloc(index) -> i8*` and `__mlir_free(i8*)` that must be implemented by the caller. These functions behave similarly to `malloc` and `free`, but can be extended to support different memory spaces in future. Allocation and deallocation instructions take care of casting the pointers. Prior to calling the allocation function, the emitted code creates an SSA Value for the descriptor and uses it to store the dynamic sizes of the MemRef passed to the allocation operation. It further emits instructions that compute the dynamic amount of memory to allocate in bytes. Finally, the allocation stores the result of calling the `__mlir_alloc` in the MemRef descriptor. Deallocation extracts the pointer to the allocated memory from the descriptor and calls `__mlir_free` on it. The descriptor itself is not modified and, being stack-allocated, ceases to exist when it goes out of scope. MLIR functions that access MemRef values as arguments or return them are converted to LLVM IR functions that accept MemRef descriptors as LLVM IR structure types by value. This significantly simplifies the calling convention at the LLVM IR level and avoids handling descriptors in the dynamic memory, however is not always comaptible with LLVM IR functions emitted from C code with similar signatures. A separate LLVM pass may be introduced in the future to provide C-compatible calling conventions for LLVM IR functions generated from MLIR. PiperOrigin-RevId: 223134883
* Lower scalar parts of CFG functions to LLVM IRAlex Zinenko2019-03-291-0/+308
Initial restricted implementaiton of the MLIR to LLVM IR translation. Introduce a new flow into the mlir-translate tool taking an MLIR module containing CFG functions only and producing and LLVM IR module. The MLIR features supported by the translator are as follows: - primitive and function types; - integer constants; - cfg and ext functions with 0 or 1 return values; - calls to these functions; - basic block conversion translation of arguments to phi nodes; - conversion between arguments of the first basic block and function arguments; - (conditional) branches; - integer addition and comparison operations. Are NOT supported: - vector and tensor types and operations on them; - memrefs and operations on them; - allocations; - functions returning multiple values; - LLVM Module triple and data layout (index type is hardcoded to i64). Create a new MLIR library and place it under lib/Target/LLVMIR. The "Target" library group is similar to the one present in LLVM and is intended to contain all future public MLIR translation targets. The general flow of MLIR to LLVM IR convresion will include several lowering and simplification passes on the MLIR itself in order to make the translation as simple as possible. In particular, ML functions should be transformed to CFG functions by the recently introduced pass, operations on structured types will be converted to sequences of operations on primitive types, complex operations such as affine_apply will be converted into sequence of primitive operations, primitive operations themselves may eventually be converted to an LLVM dialect that uses LLVM-like operations. Introduce the first translation test so that further changes make sure the basic translation functionality is not broken. PiperOrigin-RevId: 222400112
OpenPOWER on IntegriCloud