Revert "Don't use Optional::hasValue (NFC)"This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
Don't use Optional::hasValue (NFC)
[mlir] (NFC) Clean up bazel and CMake target namesAll dialect targets in bazel have been named *Dialect and all dialecttargets in CMake have been named MLIR*Dialect.
[mlir] Refactoring dialect and test code to use parseCommaSeparatedListIssue #55173Reviewed By: lattner, rriddleDifferential Revision: https://reviews.llvm.org/D124791
[mlir] Add isa/dyn_cast support for dialect interfacesThis matches the same API usage as attributes/ops/types. For example:```c++Dialect *dialect = ...;// Instead of this:if (auto *interface
[mlir] Add isa/dyn_cast support for dialect interfacesThis matches the same API usage as attributes/ops/types. For example:```c++Dialect *dialect = ...;// Instead of this:if (auto *interface = dialect->getRegisteredInterface<DialectInlinerInterface>())// You can do this:if (auto *interface = dyn_cast<DialectInlinerInterface>(dialect))```Differential Revision: https://reviews.llvm.org/D117859
show more ...
[mlir][NFC] Add a using for llvm::SMLoc/llvm::SMRange to LLVM.hThese are used pervasively during parsing.Differential Revision: https://reviews.llvm.org/D118291
Fix clang-tidy performance-move-const-arg in DLTI Dialect (NFC)The const loop iterator was inhibiting the std::move().
[mlir] Convert NamedAttribute to be a classNamedAttribute is currently represented as an std::pair, but thiscreates an extremely clunky .first/.second API. This commitconverts it to a class, with
[mlir] Convert NamedAttribute to be a classNamedAttribute is currently represented as an std::pair, but thiscreates an extremely clunky .first/.second API. This commitconverts it to a class, with better accessors (getName/getValue)and also opens the door for more convenient API in the future.Differential Revision: https://reviews.llvm.org/D113956
[mlir][NFC] Replace references to Identifier with StringAttrThis is part of the replacement of Identifier with StringAttr.Differential Revision: https://reviews.llvm.org/D113953
Use base class AsmParser/AsmPrinter in Types and Attribute print/parse method (NFC)This decouples the printing/parsing from the "context" in which the parsing occurs.This will allow to invoke thes
Use base class AsmParser/AsmPrinter in Types and Attribute print/parse method (NFC)This decouples the printing/parsing from the "context" in which the parsing occurs.This will allow to invoke these methods directly using an OpAsmParser/OpAsmPrinter.Differential Revision: https://reviews.llvm.org/D113637
[mlir] Replace usages of Identifier with StringAttrIdentifier and StringAttr essentially serve the same purpose, i.e. to hold a string value. Keeping these seemingly identical pieces of functionali
[mlir] Replace usages of Identifier with StringAttrIdentifier and StringAttr essentially serve the same purpose, i.e. to hold a string value. Keeping these seemingly identical pieces of functionality separate has caused problems in certain situations:* Identifier has nice accessors that StringAttr doesn't* Identifier can't be used as an Attribute, meaning strings are often duplicated between Identifier/StringAttr (e.g. in PDL)The only thing that Identifier has that StringAttr doesn't is support for caching a dialect that is referenced by the string (e.g. dialect.foo). This functionality is added to StringAttr, as this is useful for StringAttr in generally the same ways it was useful for Identifier.Differential Revision: https://reviews.llvm.org/D113536
[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser.The former is redundant because the later carries it as part ofits builder. Add a getContext() helper method to DialectAsmParserto ma
[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser.The former is redundant because the later carries it as part ofits builder. Add a getContext() helper method to DialectAsmParserto make this more convenient, and stop passing the context aroundexplicitly. This simplifies ODS generated parser hooks for attrsand types.This resolves PR51985Recommit 4b32f8bac4 after fixing a dependency.Differential Revision: https://reviews.llvm.org/D110796
Revert "[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser."This reverts commit 4b32f8bac40dcd1535bfe95757c3de0911bf6d1a.Seems like the build is broken with -DDBUILD_SHARED_LIBS=ON
[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser.The former is redundant because the later carries it as part ofits builder. Add a getContext() helper method to DialectAsmParserto make this more convenient, and stop passing the context aroundexplicitly. This simplifies ODS generated parser hooks for attrsand types.This resolves PR51985Differential Revision: https://reviews.llvm.org/D110796
[mlir] Update DialectAsmParser::parseString to use std::string instead of StringRefThis allows for parsing strings that have escape sequences, which require constructinga string (as they can't be
[mlir] Update DialectAsmParser::parseString to use std::string instead of StringRefThis allows for parsing strings that have escape sequences, which require constructinga string (as they can't be represented by looking at the Token contents directly).Differential Revision: https://reviews.llvm.org/D108589
[mlir] Generare .cpp.inc files for dialects.* Previously, we were only generating .h.inc files. We foresee the need to also generate implementations and this is a step towards that.* Discussed in
[mlir] Generare .cpp.inc files for dialects.* Previously, we were only generating .h.inc files. We foresee the need to also generate implementations and this is a step towards that.* Discussed in https://llvm.discourse.group/t/generating-cpp-inc-files-for-dialects/3732/2* Deviates from the discussion above by generating a default constructor in the .cpp.inc file (and adding a tablegen bit that disables this in case if this is user provided).* Generating the destructor started as a way to flush out the missing includes (produces a link error), but it is a strict improvement on its own that is worth doing (i.e. by emitting key methods in the .cpp file, we root vtables in one translation unit, which is a non-controversial improvement).Differential Revision: https://reviews.llvm.org/D105070
[mlir] support data layout specs on ModuleOpModuleOp is a natural place to provide scoped data layout information. However,it is undesirable for ModuleOp to implement the entirety ofDataLayoutOpI
[mlir] support data layout specs on ModuleOpModuleOp is a natural place to provide scoped data layout information. However,it is undesirable for ModuleOp to implement the entirety ofDataLayoutOpInterface because that would require either pushing the interfaceinside the IR library instead of a separate library, or putting the defaultimplementation of the interface as inline functions in headers leading tobinary bloat. Instead, ModuleOp accepts an arbitrary data layout spec attributeand has a dedicated hook to extract it, and DataLayout is modified to knowabout ModuleOp particularities.Reviewed By: herhut, nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D98500
[mlir] Introduce data layout modeling subsystemData layout information allows to answer questions about the size and alignmentproperties of a type. It enables, among others, the generation of vari
[mlir] Introduce data layout modeling subsystemData layout information allows to answer questions about the size and alignmentproperties of a type. It enables, among others, the generation of variouslinear memory addressing schemes for containers of abstract types and deeperreasoning about vectors. This introduces the subsystem for modeling datalayouts in MLIR.The data layout subsystem is designed to scale to MLIR's open type andoperation system. At the top level, it consists of attribute interfaces thatcan be implemented by concrete data layout specifications; type interfaces thatshould be implemented by types subject to data layout; operation interfacesthat must be implemented by operations that can serve as data layout scopes(e.g., modules); and dialect interfaces for data layout properties unrelated tospecific types. Built-in types are handled specially to decrease the overallquery cost.A concrete default implementation of these interfaces is provided in the newTarget dialect. Defaults for built-in types that match the current behavior arealso provided.Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D97067