summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Target/LLVMIR/ModuleTranslation.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [mlir] Fix translation of splat constants to LLVM IRAlex Zinenko2020-01-141-1/+8
| | | | | | | | | | | | | | | | Summary: When converting splat constants for nested sequential LLVM IR types wrapped in MLIR, the constant conversion was erroneously assuming it was always possible to recursively construct a constant of a sequential type given only one value. Instead, wait until all sequential types are unpacked recursively before constructing a scalar constant and wrapping it into the surrounding sequential type. Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72688
* [mlir] NFC: Remove Value::operator* and Value::operator-> now that Value is ↵River Riddle2020-01-111-2/+2
| | | | | | | | | | properly value-typed. Summary: These were temporary methods used to simplify the transition. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D72548
* [mlir] Fix -Wrange-loo-analysis warningsFangrui Song2020-01-011-1/+1
| | | | | | | | | | | | for (const auto &x : llvm::zip(..., ...)) -> for (auto x : llvm::zip(..., ...)) The return type of zip() is a wrapper that wraps a tuple of references. > warning: loop variable 'p' is always a copy because the range of type 'detail::zippy<detail::zip_shortest, ArrayRef<long> &, ArrayRef<long> &>' does not return a reference [-Wrange-loop-analysis]
* NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.River Riddle2019-12-231-4/+4
| | | | | | 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-5/+5
| | | | | | | | | | 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
* Detemplatize ModuleTranslation::lookupValuesAlex Zinenko2019-12-191-0/+10
| | | | | | | | | This function template has been introduced in the early days of MLIR to work around the absence of common type for ranges of values (operands, block argumeents, vectors, etc). Core IR now provides ValueRange for exactly this purpose. Use it instead of the template parameter. PiperOrigin-RevId: 286431338
* NFC: Cleanup non-conforming usages of namespaces.River Riddle2019-12-181-23/+20
| | | | | | | * Fixes use of anonymous namespace for static methods. * Uses explicit qualifiers(mlir::) instead of wrapping the definition with the namespace. PiperOrigin-RevId: 286222654
* NFC: Remove unnecessary 'llvm::' prefix from uses of llvm symbols declared ↵River Riddle2019-12-181-1/+1
| | | | | | | | in `mlir` namespace. Aside from being cleaner, this also makes the codebase more consistent. PiperOrigin-RevId: 286206974
* Move function template definition to the header file. NFCAlex Zinenko2019-12-181-11/+0
| | | | | | | | | The definition of the function template LLVM::ModuleTranslation::lookupValues has been located in a source file. As long as it has been the only file that actually called into the function, this did not cause any problem. However, it creates linking issues if the function is used from other translation units. PiperOrigin-RevId: 286203078
* Remove LLVM dependency on mlir::Module and instead check Traits.Tres Popp2019-12-161-8/+9
| | | | PiperOrigin-RevId: 285724678
* Introduce Linkage attribute to the LLVM dialectAlex Zinenko2019-12-021-3/+36
| | | | | | | | | | | LLVM IR supports linkage on global objects such as global variables and functions. Introduce the Linkage attribute into the LLVM dialect, backed by an integer storage. Use this attribute on LLVM::GlobalOp and make it mandatory. Implement parsing/printing of the attribute and conversion to LLVM IR. See tensorflow/mlir#277. PiperOrigin-RevId: 283309328
* Add support for nested symbol references.River Riddle2019-11-111-2/+2
| | | | | | | | | | | | | | | | | | This change allows for adding additional nested references to a SymbolRefAttr to allow for further resolving a symbol if that symbol also defines a SymbolTable. If a referenced symbol also defines a symbol table, a nested reference can be used to refer to a symbol within that table. Nested references are printed after the main reference in the following form: symbol-ref-attribute ::= symbol-ref-id (`::` symbol-ref-id)* Example: module @reference { func @nested_reference() } my_reference_op @reference::@nested_reference Given that SymbolRefAttr is now more general, the existing functionality centered around a single reference is moved to a derived class FlatSymbolRefAttr. Followup commits will add support to lookups, rauw, etc. for scoped references. PiperOrigin-RevId: 279860501
* [llvm] Allow GlobalOp to take a region for complex initializersJames Molloy2019-11-051-11/+23
| | | | | | | | | | | | | | | This allows GlobalOp to either take a value attribute (for simple constants) or a region that can contain IR instructions (that must be constant-foldable) to create a ConstantExpr initializer. Example: // A complex initializer is constructed with an initializer region. llvm.mlir.global constant @int_gep() : !llvm<"i32*"> { %0 = llvm.mlir.addressof @g2 : !llvm<"i32*"> %1 = llvm.mlir.constant(2 : i32) : !llvm.i32 %2 = llvm.getelementptr %0[%1] : (!llvm<"i32*">, !llvm.i32) -> !llvm<"i32*"> llvm.return %2 : !llvm<"i32*"> } PiperOrigin-RevId: 278717836
* Translation to LLVM: check the validity of module-level OpsAlex Zinenko2019-10-101-0/+8
| | | | | | | | | | | Translation to LLVM expects the entry module to have only specific types of ops that correspond to LLVM IR entities allowed in a module. Currently those are restricted to functions and globals. Introduce an additional check at the module level. Inside individual functions, the check for supported Ops is already performed, but it accepts all LLVM dialect Ops and wouldn't be immediately applicable at the module level. PiperOrigin-RevId: 274058651
* Use llvm.func to define functions with wrapped LLVM IR function typeAlex Zinenko2019-10-101-47/+8
| | | | | | | | | | | | | | This function-like operation allows one to define functions that have wrapped LLVM IR function type, in particular variadic functions. The operation was added in parallel to the existing lowering flow, this commit only switches the flow to use it. Using a custom function type makes the LLVM IR dialect type system more consistent and avoids complex conversion rules for functions that previously had to use the built-in function type instead of a wrapped LLVM IR dialect type and perform conversions during the analysis. PiperOrigin-RevId: 273910855
* Make GlobalOp's value attribute optional.Christian Sigg2019-09-211-2/+4
| | | | | | Make GlobalOp's value attribute an OptionalAttr. Change code that uses the value to handle 'nullopt'. Translate an unitialized value attribute to llvm::UndefValue. PiperOrigin-RevId: 270423646
* Add address space attribute to LLVMIR's GlobalOp.MLIR Team2019-09-191-3/+6
| | | | PiperOrigin-RevId: 270012505
* Add support for array-typed constants.MLIR Team2019-09-041-9/+21
| | | | PiperOrigin-RevId: 267121729
* LLVM dialect: prefix auxiliary operations with "mlir."Alex Zinenko2019-09-031-1/+2
| | | | | | | | | | Some of the operations in the LLVM dialect are required to model the LLVM IR in MLIR, for example "constant" operations are needed to declare a constant value since MLIR, unlike LLVM, does not support immediate values as operands. To avoid confusion with actual LLVM operations, we prefix such axuiliary operations with "mlir.". PiperOrigin-RevId: 266942838
* Add iterator support to ElementsAttr and SparseElementsAttr.River Riddle2019-08-221-2/+2
| | | | | | This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr. PiperOrigin-RevId: 264968151
* Automated rollback of commit b9dc2e481818315f2f0d87455349f497f6118a4cRiver Riddle2019-08-211-2/+2
| | | | PiperOrigin-RevId: 264672975
* Add iterator support to ElementsAttr and SparseElementsAttr.River Riddle2019-08-211-2/+2
| | | | | | This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr. PiperOrigin-RevId: 264637293
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-191-2/+2
| | | | PiperOrigin-RevId: 264193915
* Use unreachable post switch rather than default case.Jacques Pienaar2019-08-121-4/+2
| | | | | | | | Prefer to enumerate all cases in the switch instead of using default to allow compiler to flag missing cases. This also avoids -Wcovered-switch-default warning. PiperOrigin-RevId: 262935972
* LLVM dialect: introduce llvm.addressof to access globalsAlex Zinenko2019-08-121-9/+23
| | | | | | | | | | | This instruction is a local counterpart of llvm.global that takes a symbol reference to a global and produces an SSA value containing the pointer to it. Used in combination, these two operations allow one to use globals with other operations expecting SSA values. At a cost of IR indirection, we make sure the functions don't implicitly capture the surrounding SSA values and remain suitable for parallel processing. PiperOrigin-RevId: 262908622
* Translation to LLVM IR: use LogicalResult instead of boolAlex Zinenko2019-08-091-30/+26
| | | | | | | | The translation code predates the introduction of LogicalResult and was relying on the obsolete LLVM convention of returning false on success. Change it to use MLIR's LogicalResult abstraction instead. NFC. PiperOrigin-RevId: 262589432
* LLVM dialect and translation: support global stringsAlex Zinenko2019-08-091-0/+11
| | | | | | | | | | | Unlike regular constant values, strings must be placed in some memory and referred to through a pointer to that memory. Until now, they were not supported in function-local constant declarations with `llvm.constant`. Introduce support for global strings using `llvm.global`, which would translate them into global arrays in LLVM IR and thus make sure they have some memory allocated for storage. PiperOrigin-RevId: 262569316
* Translation to LLVM: support llvm.globalAlex Zinenko2019-08-091-0/+10
| | | | | | | Add support for translating recently introduced llvm.global operations to global variables in the LLVM IR proper. PiperOrigin-RevId: 262564700
* Add support for floating-point comparison 'fcmp' to the LLVM dialect.Nagy Mostafa2019-08-081-0/+39
| | | | | | | | 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
* Decouple LLVM dialect from Standard dialectAlex Zinenko2019-07-161-12/+11
| | | | | | | | | | | | | | | Due to the absence of ODS support for enum attributes, the implementation of the LLVM dialect `icmp` operation was reusing the comparison predicate from the Standard dialect, creating an avoidable library dependency. With ODS support and ICmpPredicate attribute recently introduced, the dependency is no longer justified. Update the Standard to LLVM convresion to also convert the CmpIPredicate into LLVM::ICmpPredicate and remove the unnecessary includes. Note that the MLIRLLVMIR library did not explicitly depend on MLIRStandardOps, requiring dependees of MLIRLLVMIR to also depend on MLIRStandardOps, which should no longer be the case. PiperOrigin-RevId: 258148456
* Rename FunctionAttr to SymbolRefAttr.River Riddle2019-07-121-2/+2
| | | | | | This allows for the attribute to hold symbolic references to other operations than FuncOp. This also allows for removing the dependence on FuncOp from the base Builder. PiperOrigin-RevId: 257650017
* 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
* NFC: Remove `Module::getFunctions` in favor of a general `getOps<T>`.River Riddle2019-07-081-2/+2
| | | | | | 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: Refactor Module to be value typed.River Riddle2019-07-021-4/+4
| | | | | | 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-2/+2
| | | | | | 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
* Add a new AttributeElementIterator to DenseElementsAttr.River Riddle2019-06-261-3/+1
| | | | | | This allows for iterating over the internal elements via an iterator_range of Attribute, and also allows for removing the final SmallVectorImpl based 'getValues' method. PiperOrigin-RevId: 255309555
* Move the emitError/Warning/Remark utility methods out of MLIRContext and ↵River Riddle2019-06-251-12/+7
| | | | | | | | 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
* Simplify usages of SplatElementsAttr now that it inherits from ↵River Riddle2019-06-191-8/+1
| | | | | | DenseElementsAttr. PiperOrigin-RevId: 253910543
* Refactor DenseElementsAttr to support auto-splatting the dense data on ↵River Riddle2019-06-191-0/+7
| | | | | | construction. This essentially means that we always auto-detect splat data and only store the minimum amount of data necessary. Support for parsing dense splats, and removing SplatElementsAttr(now that it is redundant) will come in followup cls PiperOrigin-RevId: 252720561
* Add support for llvm.constant with StringAttr as value.Stephan Herhut2019-06-011-0/+5
| | | | | | | | | These are translated to an llvm::ConstantDataArray on translation to llvm IR proper. -- PiperOrigin-RevId: 249813111
* Refactor FunctionAttr to hold the internal function reference by name ↵River Riddle2019-06-011-3/+2
| | | | | | | | | | | | | | | | 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 support for streaming an OperationName into a Diagnostic.River Riddle2019-05-201-2/+1
| | | | | | -- PiperOrigin-RevId: 248987646
* Remove unnecessary C++ specifier in CPP files. NFC.Jacques Pienaar2019-05-201-1/+1
| | | | | | | | These are only required in .h files to disambiguate between C and C++ header files. -- PiperOrigin-RevId: 248219135
* Add a utility method to MLIRContext get a registered dialect with the ↵River Riddle2019-05-201-3/+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
* Replace Operation::isa with llvm::isa.River Riddle2019-05-201-2/+2
| | | | | | -- PiperOrigin-RevId: 247789235
* Add support for using llvm::dyn_cast/cast/isa for operation casts and ↵River Riddle2019-05-201-3/+3
| | | | | | | | replace usages of Operation::dyn_cast with llvm::dyn_cast. -- PiperOrigin-RevId: 247780086
* Automated rollback of changelist 247778391.MLIR Team2019-05-201-3/+3
| | | | PiperOrigin-RevId: 247778691
* Add support for using llvm::dyn_cast/cast/isa for operation casts and ↵River Riddle2019-05-201-3/+3
| | | | | | | | replace usages of Operation::dyn_cast with llvm::dyn_cast. -- PiperOrigin-RevId: 247778391
OpenPOWER on IntegriCloud