15 Commits

Author SHA1 Message Date
Ramkumar Ramachandra
db791b278a
mlir/LogicalResult: move into llvm (#97309)
This patch is part of a project to move the Presburger library into
LLVM.
2024-07-02 10:42:33 +01:00
Fehr Mathieu
3dbac2c007
[mlir] Expose type and attribute names in the MLIRContext and abstract type/attr classes (#72189)
This patch expose the type and attribute names in C++ as methods in the
`AbstractType` and `AbstractAttribute` classes, and keep a map of names
to `AbstractType` and `AbstractAttribute` in the `MLIRContext`. Type and
attribute names should be unique.

It adds support in ODS to generate the `getName` methods in
`AbstractType` and `AbstractAttribute`, through the use of two new
variables, `typeName` and `attrName`. It also adds names to C++-defined
type and attributes.
2023-12-01 00:39:34 +01:00
Tres Popp
c1fa60b4cd [mlir] Update method cast calls to function calls
The MLIR classes Type/Attribute/Operation/Op/Value support
cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast
functionality in addition to defining methods with the same name.
This change begins the migration of uses of the method to the
corresponding function call as has been decided as more consistent.

Note that there still exist classes that only define methods directly,
such as AffineExpr, and this does not include work currently to support
a functional cast/isa call.

Context:

* https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…"
* Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443

Implementation:
This follows a previous patch that updated calls
`op.cast<T>()-> cast<T>(op)`. However some cases could not handle an
unprefixed `cast` call due to occurrences of variables named cast, or
occurring inside of class definitions which would resolve to the method.
All C++ files that did not work automatically with `cast<T>()` are
updated here to `llvm::cast` and similar with the intention that they
can be easily updated after the methods are removed through a
find-replace.

See https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check
for the clang-tidy check that is used and then update printed
occurrences of the function to include `llvm::` before.

One can then run the following:
```
ninja -C $BUILD_DIR clang-tidy

run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\
                 -export-fixes /tmp/cast/casts.yaml mlir/*\
                 -header-filter=mlir/ -fix

rm -rf $BUILD_DIR/tools/mlir/**/*.inc
```

Differential Revision: https://reviews.llvm.org/D150348
2023-05-12 11:21:30 +02:00
River Riddle
03d136cf5f [mlir] Promote the SubElementInterfaces to a core Attribute/Type construct
This commit restructures the sub element infrastructure to be a core part
of attributes and types, instead of being relegated to an interface. This
establishes sub element walking/replacement as something "always there",
which makes it easier to rely on for correctness/etc (which various bits of
infrastructure want, such as Symbols).

Attribute/Type now have `walk` and `replace` methods directly
accessible, which provide power API for interacting with sub elements. As
part of this, a new AttrTypeWalker class is introduced that supports caching
walked attributes/types, and a friendlier API (see the simplification of symbol
walking in SymbolTable.cpp).

Differential Revision: https://reviews.llvm.org/D142272
2023-01-27 15:28:03 -08:00
River Riddle
83a635c0d4 [mlir] Add support for interface inheritance
This allows for interfaces to define a set of "base classes",
which are interfaces whose methods/extra class decls/etc.
should be inherited by the derived interface. This more
easily enables combining interfaces and their dependencies,
without lots of awkard casting. Additional implicit conversion
operators also greatly simplify the conversion process.

One other aspect of this "inheritance" is that we also implicitly
add the base interfaces to the attr/op/type. The user can still
add them manually if desired, but this should help remove some
of the boiler plate when an interface has dependencies.

See https://discourse.llvm.org/t/interface-inheritance-and-dependencies-interface-method-visibility-interface-composition

Differential Revision: https://reviews.llvm.org/D140198
2023-01-18 19:16:30 -08:00
Mehdi Amini
0441272c45 Revert "Revert "Refactor OperationName to use virtual tables for dispatch (NFC)""
This streamlines the implementation and makes it so that the virtual
tables are in the binary instead of dynamically assembled during initialization.
The dynamic allocation size of op registration is also smaller with this
change.

This reverts commit 7bf1e441da6b59a25495fde8e34939f93548cc6d
and re-introduce e055aad5ffb348472c65dfcbede85f39efe8f906
after fixing the windows crash by making ParseAssemblyFn a
unique_function again

Differential Revision: https://reviews.llvm.org/D141492
2023-01-16 23:58:48 +00:00
Mehdi Amini
7bf1e441da Revert "Refactor OperationName to use virtual tables for dispatch (NFC)"
This reverts commit e055aad5ffb348472c65dfcbede85f39efe8f906.

This crashes on Windows at the moment for some reasons.
2023-01-16 23:11:38 +00:00
Mehdi Amini
e055aad5ff Refactor OperationName to use virtual tables for dispatch (NFC)
This streamlines the implementation and makes it so that the virtual tables are in the binary instead of dynamically assembled during initialization.
The dynamic allocation size of op registration is also smaller with this
change.

Differential Revision: https://reviews.llvm.org/D141492
2023-01-14 01:27:38 +00:00
Kazu Hirata
1a36588ec6 [mlir] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated.  The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-03 18:50:27 -08:00
Mathieu Fehr
ba8424a251 [mlir] Add Dynamic Dialects
Dynamic dialects are dialects that can be defined at runtime.
Dynamic dialects are extensible by new operations, types, and
attributes at runtime.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D125201
2022-09-19 09:58:18 -07:00
Jacques Pienaar
69b6454fff [mlir] Plumb through default attribute populate for extensible dialect. 2022-07-13 09:05:04 -07:00
Jacques Pienaar
82140ad728 [mlir] Add method to populate default attributes
Previously default attributes were only usable by way of the ODS generated
accessors, but this was undesirable as
1. The ODS getters could construct Attribute each get request;
2. For non-C++ uses this would require either duplicating some of tee default
   attribute generating or generating additional bindings to generate methods;
3. Accessing op.getAttr("foo") and op.getFoo() would return different results;
Generate method to populate default attributes that can be used to address
these.

This merely adds this facility but does not employ by default on any path.

Differential Revision: https://reviews.llvm.org/D128962
2022-07-08 11:31:13 -07:00
Mathieu Fehr
9e0b553359 [mlir] Add extensible dialects
Depends on D104534
Add support for extensible dialects, which are dialects that can be
extended at runtime with new operations and types.

These operations and types cannot at the moment implement traits
or interfaces.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D104554
2022-04-26 19:48:22 -07:00
Andrzej Warzynski
1b2e35e4d4 Revert "[mlir] Add extensible dialects"
This reverts commit dbe9f0914fcfd8444fd9656821af0f1a34a27e7a.

The flang-x86_64-windows buildbot has been failing since this has been merged:
* https://lab.llvm.org/buildbot/#/builders/172/builds/9124
Similar failure was reported by the pre-commit CI.
2022-03-03 10:30:50 +00:00
Mathieu Fehr
dbe9f0914f [mlir] Add extensible dialects
Add support for extensible dialects, which are dialects that can be
extended at runtime with new operations and types.

These operations and types cannot at the moment implement traits
or interfaces.

Differential Revision: https://reviews.llvm.org/D104554
2022-03-02 12:42:59 -08:00