[mlir][IR] Remove factory methods from `FloatType` (#123026)

This commit removes convenience methods from `FloatType` to make it
independent of concrete interface implementations.

See discussion

[mlir][IR] Remove factory methods from `FloatType` (#123026)

This commit removes convenience methods from `FloatType` to make it
independent of concrete interface implementations.

See discussion here:
https://discourse.llvm.org/t/rethink-on-approach-to-low-precision-fp-types/82361

Note for LLVM integration: Replace `FloatType::getF32(` with
`Float32Type::get(` etc.

show more ...

[mlir] Fix allocateAndCopyWithAlign for immutable (#108679)

Previously this would assert when attempting to getMutableData.

[mlir] Nits on uses of llvm::raw_string_ostream (NFC)

* Don't call raw_string_ostream::flush(), which is essentially a no-op
* Strip unneeded calls to raw_string_ostream::str(), to avoid excess indi

[mlir] Nits on uses of llvm::raw_string_ostream (NFC)

* Don't call raw_string_ostream::flush(), which is essentially a no-op
* Strip unneeded calls to raw_string_ostream::str(), to avoid excess indirection.

show more ...

[mlir] Attribute add printStripped (#78008)

Enable printing without dialect wrapping.

This closely matches `AsmPrinter::printStrippedAttrOrType`
implementation wise except templating component.

Improve MLIR Attribute::get() method efficiency by reducing the amount of argument copies (#68067)

This ensures that the proper std::forward/std::move are involved, we go from 6
copy-constructions

Improve MLIR Attribute::get() method efficiency by reducing the amount of argument copies (#68067)

This ensures that the proper std::forward/std::move are involved, we go from 6
copy-constructions to 0 (!) on Attribute creation in release builds.

show more ...

[mlir] Add `empty` to `StringAttr`

It was common to see `value.getValue().empty()` or `value.size()`
instead of the idiomatic `value.empty()`.

Depends on D159455

Differential Revision: https://rev

[mlir] Add `empty` to `StringAttr`

It was common to see `value.getValue().empty()` or `value.size()`
instead of the idiomatic `value.empty()`.

Depends on D159455

Differential Revision: https://reviews.llvm.org/D159456

show more ...

[mlir] Fix for MSVC bool splat issue encountered.

When building MLIR using bazel on windows with MSVC2019, bool splats
were being created incorrectly:

```
dense<[true,true,true,true]> : tensor<4xi1

[mlir] Fix for MSVC bool splat issue encountered.

When building MLIR using bazel on windows with MSVC2019, bool splats
were being created incorrectly:

```
dense<[true,true,true,true]> : tensor<4xi1>
-(parse with mlir-opt)-> dense<[true, false, false, false]> : tensor<4xi1>
```

Appears that a Windows bazel build produces a corrupt DenseIntOrFPElementsAttr.
Unable to repro using MSVC and cmake.

Issue first discovered here:
https://github.com/google/jax/issues/16394

Added test point for reproduction:

```
$ bazel test @llvm-project//mlir/unittests:ir_tests --test_arg=--gtest_filter=DenseSplatTest.BoolSplatSmall
```

Differential Revision: https://reviews.llvm.org/D155745

show more ...

[mlir] Move casting calls from methods 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
functionali

[mlir] Move casting calls from methods 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.

Caveats include:
- This clang-tidy script probably has more problems.
- This only touches C++ code, so nothing that is being generated.

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 first patch was created with the following steps. The intention is
to only do automated changes at first, so I waste less time if it's
reverted, and so the first mass change is more clear as an example to
other teams that will need to follow similar steps.

Steps are described per line, as comments are removed by git:
0. Retrieve the change from the following to build clang-tidy with an
additional check:
https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check
1. Build clang-tidy
2. Run clang-tidy over your entire codebase while disabling all checks
and enabling the one relevant one. Run on all header files also.
3. Delete .inc files that were also modified, so the next build rebuilds
them to a pure state.
4. Some changes have been deleted for the following reasons:
- Some files had a variable also named cast
- Some files had not included a header file that defines the cast
functions
- Some files are definitions of the classes that have the casting
methods, so the code still refers to the method instead of the
function without adding a prefix or removing the method declaration
at the same time.

```
ninja -C $BUILD_DIR clang-tidy

run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\
-header-filter=mlir/ mlir/* -fix

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

git restore mlir/lib/IR mlir/lib/Dialect/DLTI/DLTI.cpp\
mlir/lib/Dialect/Complex/IR/ComplexDialect.cpp\
mlir/lib/**/IR/\
mlir/lib/Dialect/SparseTensor/Transforms/SparseVectorization.cpp\
mlir/lib/Dialect/Vector/Transforms/LowerVectorMultiReduction.cpp\
mlir/test/lib/Dialect/Test/TestTypes.cpp\
mlir/test/lib/Dialect/Transform/TestTransformDialectExtension.cpp\
mlir/test/lib/Dialect/Test/TestAttributes.cpp\
mlir/unittests/TableGen/EnumsGenTest.cpp\
mlir/test/python/lib/PythonTestCAPI.cpp\
mlir/include/mlir/IR/
```

Differential Revision: https://reviews.llvm.org/D150123

show more ...

[mlir] Adjust AttributeTest to show skip behavior.

walk() skips identical sub-attributes. Adjust the unit test to show
this.

Differential Revision: https://reviews.llvm.org/D142956

[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 relegat

[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

show more ...

[mlir] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is pa

[mlir] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

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

show more ...

[mlir] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optiona

[mlir] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
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

show more ...

Move from llvm::makeArrayRef to ArrayRef deduction guides - last part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

Differential Re

Move from llvm::makeArrayRef to ArrayRef deduction guides - last part

This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

Differential Revision: https://reviews.llvm.org/D141298

show more ...

[mlir] Fix DenseElementsAttr treatment of bool splat of "true"

Boolean splats currently can't roundtrip via the "raw" DenseElementsAttr
API. This is because internally we treat true splats in some c

[mlir] Fix DenseElementsAttr treatment of bool splat of "true"

Boolean splats currently can't roundtrip via the "raw" DenseElementsAttr
API. This is because internally we treat true splats in some cases as "1"(one bit set)
and in other cases as "0xFF"(all bits set). This commit cleans up this handling to
consistently use 0xFF (all bits set) as the value for a splat of true.

Differential Revision: https://reviews.llvm.org/D133743

show more ...

[mlir] Fix DenseElementsAttr::mapValues(i1, splat).

Splat of bool is encoded as a byte with all-ones in it [1]. Without this
change, this piece of code:

auto xs = builder.getI32TensorAttr({42,

[mlir] Fix DenseElementsAttr::mapValues(i1, splat).

Splat of bool is encoded as a byte with all-ones in it [1]. Without this
change, this piece of code:

auto xs = builder.getI32TensorAttr({42, 42, 42, 42});
auto xs2 = xs.mapValues(builder.getI1Type(), [](const llvm::APInt &x) {
return x.isZero() ? llvm::APInt::getZero(1) : llvm::APInt::getAllOnes(1);
});
xs2.dump();

Prints:

dense<[true, false, false, false]> : tensor<4xi1>

Because only the first bit is set. This applies to both
DenseIntElementsAttr::mapValues() and DenseFPElementsAttr::mapValues().

[1]: https://github.com/llvm/llvm-project/blob/e877b42e2c70813352c1963ea33e992f481d5cba/mlir/lib/IR/BuiltinAttributes.cpp#L984

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D132767

show more ...

Reland "[mlir][test] Fix IR/AttributeTest.cpp compilation on Solaris"

The `IR/AttributeTest.cpp` test fails to compile on Solaris:
```
/vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTes

Reland "[mlir][test] Fix IR/AttributeTest.cpp compilation on Solaris"

The `IR/AttributeTest.cpp` test fails to compile on Solaris:
```
/vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:223:36: error: no matching function for call to 'allocate'
AttrT::get(type, "resource", UnmanagedAsmResourceBlob::allocate(data));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:237:3: note: in instantiation of function template specialization 'checkNativeAccess<mlir::detail::DenseResourceElementsAttrBase<int8_t>, char>' requested here
checkNativeAccess<AttrT, T>(builder.getContext(), llvm::makeArrayRef(data),
^
/vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:258:3: note: in instantiation of function template specialization 'checkNativeIntAccess<mlir::detail::DenseResourceElementsAttrBase<int8_t>, char>' requested here
checkNativeIntAccess<DenseI8ResourceElementsAttr, int8_t>(builder, 8);
^
/vol/llvm/src/llvm-project/local/mlir/include/mlir/IR/AsmState.h:221:3: note: candidate template ignored: requirement '!std::is_same<char, char>::value' was not satisfied [with T = char]
allocate(ArrayRef<T> data, bool dataIsMutable = false) {
^
/vol/llvm/src/llvm-project/local/mlir/include/mlir/IR/AsmState.h:214:26: note: candidate function not viable: requires at least 2 arguments, but 1 was provided
static AsmResourceBlob allocate(ArrayRef<char> data, size_t align,
^
```
Because `char` is `signed` by default on Solaris and `int8_t` is
`char`. `std::is_same<int8_t, char>` is `true` unlike elsewhere, rejecting
the one-arg `allocate` overload.

Fixed by renaming the two overloads to avoid the ambiguity.

Tested on `amd64-pc-solaris2.11` ,`sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.

Differential Revision: https://reviews.llvm.org/D131148

show more ...

[mlir, flang] Use has_value instead of hasValue (NFC)

Revert "[mlir][test] Fix IR/AttributeTest.cpp compilation on Solaris"

This reverts commit 07aaa35f74d845a20d48e644671dce150ebf7748.

This breaks the Windows bot, and while the fix addressed the
`cha

Revert "[mlir][test] Fix IR/AttributeTest.cpp compilation on Solaris"

This reverts commit 07aaa35f74d845a20d48e644671dce150ebf7748.

This breaks the Windows bot, and while the fix addressed the
`char`/`int8_t` case, it does not make sense for other cases like
`float`.

show more ...

[mlir][test] Fix IR/AttributeTest.cpp compilation on Solaris

The `IR/AttributeTest.cpp` test fails to compile on Solaris:

/vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:223:

[mlir][test] Fix IR/AttributeTest.cpp compilation on Solaris

The `IR/AttributeTest.cpp` test fails to compile on Solaris:

/vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:223:36: error: no matching function for call to 'allocate'
AttrT::get(type, "resource", UnmanagedAsmResourceBlob::allocate(data));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:237:3: note: in instantiation of function template specialization 'checkNativeAccess<mlir::detail::DenseResourceElementsAttrBase<int8_t>, char>' requested here
checkNativeAccess<AttrT, T>(builder.getContext(), llvm::makeArrayRef(data),
^
/vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:258:3: note: in instantiation of function template specialization 'checkNativeIntAccess<mlir::detail::DenseResourceElementsAttrBase<int8_t>, char>' requested here
checkNativeIntAccess<DenseI8ResourceElementsAttr, int8_t>(builder, 8);
^
/vol/llvm/src/llvm-project/local/mlir/include/mlir/IR/AsmState.h:221:3: note: candidate template ignored: requirement '!std::is_same<char, char>::value' was not satisfied [with T = char]
allocate(ArrayRef<T> data, bool dataIsMutable = false) {
^
/vol/llvm/src/llvm-project/local/mlir/include/mlir/IR/AsmState.h:214:26: note: candidate function not viable: requires at least 2 arguments, but 1 was provided
static AsmResourceBlob allocate(ArrayRef<char> data, size_t align,
^

I suspect this happens because `char` is `signed` by default on Solaris.

Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.

Differential Revision: https://reviews.llvm.org/D131148

show more ...

[mlir] Use EXPECT_DEBUG_DEATH in unit test

This allows the tests to also pass when compiled in opt mode.

[mlir] Add a new builtin DenseResourceElementsAttr

This attributes is intended cover the current set of use cases that abuse
DenseElementsAttr, e.g. when the data is large. Using resources for large

[mlir] Add a new builtin DenseResourceElementsAttr

This attributes is intended cover the current set of use cases that abuse
DenseElementsAttr, e.g. when the data is large. Using resources for large
data is one of the major reasons why they were added; e.g. they can be
deallocated mid-compilation, they support a wide variety of data origins
(e.g, heap allocated, mmap'd, etc.), they can support mutation, etc.

I considered at length not having a builtin variant of this, and instead
having multiple versions of this attribute for dialects that are interested,
but they all boiled down to the exact same attribute definition. Given the
generality of this attribute, it feels more aligned to keep it next to DenseArrayAttr
(given that DenseArrayAttr covers the "small" case, and DenseResourcesElementsAttr
covers the "large" case). The underlying infra used to build this attribute is
general, and having a builtin attribute doesn't preclude users from defining
their own when it makes sense (they can even share a blob manager with the
builtin dialect to avoid data duplication).

Differential Revision: https://reviews.llvm.org/D130022

show more ...

[mlir] Remove types from attributes

This patch removes the `type` field from `Attribute` along with the
`Attribute::getType` accessor.

Going forward, this means that attributes in MLIR will no long

[mlir] Remove types from attributes

This patch removes the `type` field from `Attribute` along with the
`Attribute::getType` accessor.

Going forward, this means that attributes in MLIR will no longer have
types as a first-class concept. This patch lays the groundwork to
incrementally remove or refactor code that relies on generic attributes
being typed. The immediate impact will be on attributes that rely on
`Attribute` containing a type, such as `IntegerAttr`,
`DenseElementsAttr`, and `ml_program::ExternAttr`, which will now need
to define a type parameter on their storage classes. This will save
memory as all other attribute kinds will no longer contain a type.

Moreover, it will not be possible to generically query the type of an
attribute directly. This patch provides an attribute interface
`TypedAttr` that implements only one method, `getType`, which can be
used to generically query the types of attributes that implement the
interface. This interface can be used to retain the concept of a "typed
attribute". The ODS-generated accessor for a `type` parameter
automatically implements this method.

Next steps will be to refactor the assembly formats of certain operations
that rely on `parseAttribute(type)` and `printAttributeWithoutType` to
remove special handling of type elision until `type` can be removed from
the dialect parsing hook entirely; and incrementally remove uses of
`TypedAttr`.

Reviewed By: lattner, rriddle, jpienaar

Differential Revision: https://reviews.llvm.org/D130092

show more ...

Adjust "end namespace" comment in MLIR to match new agree'd coding style

See D115115 and this mailing list discussion:
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html

Differenti

Adjust "end namespace" comment in MLIR to match new agree'd coding style

See D115115 and this mailing list discussion:
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html

Differential Revision: https://reviews.llvm.org/D115309

show more ...

[mlir][NFC] Replace references to Identifier with StringAttr

This is part of the replacement of Identifier with StringAttr.

Differential Revision: https://reviews.llvm.org/D113953

[mlir] Refactor ElementsAttr's value access API

There are several aspects of the API that either aren't easy to use, or are
deceptively easy to do the wrong thing. The main change of this commit
is

[mlir] Refactor ElementsAttr's value access API

There are several aspects of the API that either aren't easy to use, or are
deceptively easy to do the wrong thing. The main change of this commit
is to remove all of the `getValue<T>`/`getFlatValue<T>` from ElementsAttr
and instead provide operator[] methods on the ranges returned by
`getValues<T>`. This provides a much more convenient API for the value
ranges. It also removes the easy-to-be-inefficient nature of
getValue/getFlatValue, which under the hood would construct a new range for
the type `T`. Constructing a range is not necessarily cheap in all cases, and
could lead to very poor performance if used within a loop; i.e. if you were to
naively write something like:

```
DenseElementsAttr attr = ...;
for (int i = 0; i < size; ++i) {
// We are internally rebuilding the APFloat value range on each iteration!!
APFloat it = attr.getFlatValue<APFloat>(i);
}
```

Differential Revision: https://reviews.llvm.org/D113229

show more ...