[mlir] Start migrating more dialects to prefixed formMarked all dialects that could be (reasonably) easily flipped to _Bothprefix. Updating the accessors to prefixed form will happen in followup,
[mlir] Start migrating more dialects to prefixed formMarked all dialects that could be (reasonably) easily flipped to _Bothprefix. Updating the accessors to prefixed form will happen in followup, this was to flush out conflicts and to mark all dialects explicitlyas I plan to flip OpBase default to _Prefixed to avoid needing tomigrate new dialects.Except for Standalone example which got flipped to _Prefixed.Differential Revision: https://reviews.llvm.org/D128027
show more ...
[mlir] Attach InferTypeOpInterface on SameOperandsAndResultType operations when possibleThis allows for inferring the result types of operations in certain situations by using the type ofan operan
[mlir] Attach InferTypeOpInterface on SameOperandsAndResultType operations when possibleThis allows for inferring the result types of operations in certain situations by using the type ofan operand. This commit allowed for automatically supporting type inference for many moreoperations with no additional effort, e.g. nearly all Arithmetic operations now supportresult type inferrence with no additional changes.Differential Revision: https://reviews.llvm.org/D124581
Remove OpTrait, AttrTrait and TypeTrait - Remove the `{Op,Attr,Type}Trait` TableGen classes and replace with `Trait` - Rename `OpTraitList` to `TraitList` and use it in a few placesThe bulk of
Remove OpTrait, AttrTrait and TypeTrait - Remove the `{Op,Attr,Type}Trait` TableGen classes and replace with `Trait` - Rename `OpTraitList` to `TraitList` and use it in a few placesThe bulk of this change is a mechanical s/OpTrait/Trait/ throughout the codebase.Reviewed By: rriddle, jpienaar, herhutDifferential Revision: https://reviews.llvm.org/D118543
[mlir] Move trait to InferTypeOpInterfaceStep towards removing the hard coded behavior for this trait and to instead use common interface.Differential Revision: https://reviews.llvm.org/D114208
Re-apply "[mlir] Allow out-of-tree python building from installed MLIR."Re-applies D111513:* Adds a full-fledged Python example dialect and tests to the Standalone example (need to do a bit of twe
Re-apply "[mlir] Allow out-of-tree python building from installed MLIR."Re-applies D111513:* Adds a full-fledged Python example dialect and tests to the Standalone example (need to do a bit of tweaking in the top level CMake and lit tests to adapt better to if not building with Python enabled).* Rips out remnants of custom extension building in favor of pybind11_add_module which does the right thing.* Makes python and extension sources installable (outputs to src/python/${name} in the install tree): Both Python and C++ extension sources get installed as downstreams need all of this in order to build a derived version of the API.* Exports sources targets (with our properties that make everything work) by converting them to INTERFACE libraries (which have export support), as recommended for the forseeable future by CMake devs. Renames custom properties to start with lower-case letter, as also recommended/required (groan).* Adds a ROOT_DIR argument to declare_mlir_python_extension since now all C++ sources for an extension must be under the same directory (to line up at install time).* Downstreams will need to adapt by: * Remove absolute paths from any SOURCES for declare_mlir_python_extension (I believe all downstreams are just using ${CMAKE_CURRENT_SOURCE_DIR} here, which can just be ommitted). May need to set ROOT_DIR if not relative to the current source directory. * To allow further downstreams to install/build, will need to make sure that all C++ extension headers are also listed under SOURCES for declare_mlir_python_extension.This reverts commit 1a6c26d1f52999edbfbf6a978ae3f0e6759ea755.Reviewed By: stephenneuendorfferDifferential Revision: https://reviews.llvm.org/D113732
Revert "[mlir] Allow out-of-tree python building from installed MLIR."This reverts commit c7be8b75399c727ec9e1ddc3f81510f284c65155.Build is broken (multiple buildbots)
[mlir] Allow out-of-tree python building from installed MLIR.* Depends on D111504, which provides the boilerplate for building aggregate shared libraries from installed MLIR.* Adds a full-fledged
[mlir] Allow out-of-tree python building from installed MLIR.* Depends on D111504, which provides the boilerplate for building aggregate shared libraries from installed MLIR.* Adds a full-fledged Python example dialect and tests to the Standalone example (need to do a bit of tweaking in the top level CMake and lit tests to adapt better to if not building with Python enabled).* Rips out remnants of custom extension building in favor of `pybind11_add_module` which does the right thing.* Makes python and extension sources installable (outputs to src/python/${name} in the install tree): Both Python and C++ extension sources get installed as downstreams need all of this in order to build a derived version of the API.* Exports sources targets (with our properties that make everything work) by converting them to INTERFACE libraries (which have export support), as recommended for the forseeable future by CMake devs. Renames custom properties to start with lower-case letter, as also recommended/required (groan).* Adds a ROOT_DIR argument to `declare_mlir_python_extension` since now all C++ sources for an extension must be under the same directory (to line up at install time).* Need to validate against a downstream or two and adjust, prior to submitting.Downstreams will need to adapt by:* Remove absolute paths from any SOURCES for `declare_mlir_python_extension` (I believe all downstreams are just using `${CMAKE_CURRENT_SOURCE_DIR}` here, which can just be ommitted). May need to set `ROOT_DIR` if not relative to the current source directory.* To allow further downstreams to install/build, will need to make sure that all C++ extension headers are also listed under SOURCES for `declare_mlir_python_extension`.Reviewed By: stephenneuendorffer, mikeurbachDifferential Revision: https://reviews.llvm.org/D111513
[MLIR][arith] fix references to std.constant in commentsReviewed By: jpienaarDifferential Revision: https://reviews.llvm.org/D111820
Change add_mlir_doc CMake macro to take the tablegen command as last argument to allow extra flagsThis is useful for expressing specific table-gen options, like selectinga particular dialect to pr
Change add_mlir_doc CMake macro to take the tablegen command as last argument to allow extra flagsThis is useful for expressing specific table-gen options, like selectinga particular dialect to print.Use it to fix the documentation for the `pdl_interp` dialect which is nowgenerating the first dialect it finds in its input which is `pdl`.Differential Revision: https://reviews.llvm.org/D100517
[ODS] Make the getType() method on a OneResult instruction return a specific type.Implement Bug 46698, making ODS synthesize a getType() method that returns aspecific C++ class for OneResult metho
[ODS] Make the getType() method on a OneResult instruction return a specific type.Implement Bug 46698, making ODS synthesize a getType() method that returns aspecific C++ class for OneResult methods where we know that class. This eliminatesa common source of casts in things like: myOp.getType().cast<FIRRTLType>().getPassive()because we know that myOp always returns a FIRRTLType. This also encouragesop authors to type their results more tightly (which is also good forverification).I chose to implement this by splitting the OneResult trait into itself plus aOneTypedResult trait, given that many things are using `hasTrait<OneResult>`to conditionalize various logic.While this changes makes many many ops get more specific getType() results, itis generally drop-in compatible with the previous behavior because 'x.cast<T>()'is allowed when x is already known to be a T. The one exception to this is thatwe need declarations of the types used by ops, which is why a couple headersneeded additional #includes.I updated a few things in tree to remove the now-redundant `.cast<>`'s, but thereare probably many more than can be removed.Differential Revision: https://reviews.llvm.org/D93790
Fix MLIR standalone example to properly handle namespaceODS TableGen backend now requires to spell out which namespace they haveto be nested in, in an absolute way.
[MLIR] Continue renaming of "SideEffects"MLIRSideEffects -> MLIRSideEffectInterfacesSideEffects.h -> SideEffectInterfaces.hSideEffects.cpp -> SideEffectInterface.cppNote that I haven't renamed
[MLIR] Continue renaming of "SideEffects"MLIRSideEffects -> MLIRSideEffectInterfacesSideEffects.h -> SideEffectInterfaces.hSideEffects.cpp -> SideEffectInterface.cppNote that I haven't renamed TableGen/SideEffects.h or TableGen/SideEffects.cppfind -name "*.h" -exec sed -i "s/SideEffects.h/SideEffectInterfaces.h/" "{}" \;find -name "CMakeLists.txt" -exec sed -i "s/MLIRSideEffects/MLIRSideEffectInterfaces/" "{}" \;Differential Revision: https://reviews.llvm.org/D79890
[MLIR] Rename SideEffects.td -> SideEffectInterfaces.tdThis normalize the name of the tablegen file with the name of the generatedfiles (SideEffectInterfaces.h.inc) and the other Interface tablege
[MLIR] Rename SideEffects.td -> SideEffectInterfaces.tdThis normalize the name of the tablegen file with the name of the generatedfiles (SideEffectInterfaces.h.inc) and the other Interface tablegen files,which all end in Interface(s).tdDifferential Revision: https://reviews.llvm.org/D79517
[mlir] Add an out-of-tree dialect exampleThis adds a minimal out-of-tree dialect template which can be used to start work on a standalone dialect implementation without having to integrate it in th
[mlir] Add an out-of-tree dialect exampleThis adds a minimal out-of-tree dialect template which can be used to start work on a standalone dialect implementation without having to integrate it in the main LLVM tree.It mostly sets up the directory structure and provides CMakeLists.txt files to build a dialect library, an opt-like tool to operate on that dialect as well as tests. It could be expanded in the future to add examples of more user-defined operations, types, attributes, generated enums, transforms, etc. and linked to a tutorial.Differential Revision: https://reviews.llvm.org/D77133