[MLIR][DLTI] Pretty parsing and printing for DLTI attrs (#113365)

Unifies parsing and printing for DLTI attributes. Introduces a format of
`#dlti.attr<key1 = val1, ..., keyN = valN>` syntax for all

[MLIR][DLTI] Pretty parsing and printing for DLTI attrs (#113365)

Unifies parsing and printing for DLTI attributes. Introduces a format of
`#dlti.attr<key1 = val1, ..., keyN = valN>` syntax for all queryable
DLTI attributes similar to that of the DictionaryAttr, while retaining
support for specifying key-value pairs with `#dlti.dl_entry` (whether to
retain this is TBD).

As the new format does away with most of the boilerplate, it is much easier
to parse for humans. This makes an especially big difference for nested
attributes.

Updates the DLTI-using tests and includes fixes for misc error checking/
error messages.

show more ...

[MLIR][DLTI] Introduce DLTIQueryInterface and impl for DLTI attrs (#104595)

This new interface is supposed to capture the core functionality of
DLTI: querying for values at keys. As such this new i

[MLIR][DLTI] Introduce DLTIQueryInterface and impl for DLTI attrs (#104595)

This new interface is supposed to capture the core functionality of
DLTI: querying for values at keys. As such this new interface unifies
the ability to query DLTI attributes in a single method: query(). All
existing DLTI interfaces exposing their own query methods now 1) now
extend this new interface and 2) provide a default implementation for
`query()`.

As DLTIQueryInterface::query() returns an attribute, it naturally
enables recursive queries on nested DLTI attrs. A utility function,
`dlti::query()`, implements the logic for nested lookups.

A new `#dlti.map` attribute is introduced to capture the most generic
form of a finite DLTI-mapping. One of the benefits is that it allows for
more easily encoding hierachical information that is suitably queryable,
i.e. by means of nested attributes.

In line with the above, `transform.dlti.query` is modified so as to take
an arbitrary number of keys and to perform a nested lookup using the
above utility function.

show more ...

DLTI: Simplifying getDevicePropertyValue API by returning Attribute type value (#96706)

**Rationale**

- With the current flexibility of supporting any type of value, we will
need to offer type-s

DLTI: Simplifying getDevicePropertyValue API by returning Attribute type value (#96706)

**Rationale**

- With the current flexibility of supporting any type of value, we will
need to offer type-specific APIs to fetch a value (e.g.,
`getDevicePropertyValueAsInt` for integer type,
`getDevicePropertyValueAsFloat` for float type, etc.) A single type of
value will eliminate this need.
- Current flexibility can also lead to typing errors when a user fetches
the value of a property using an API that is not consistent with the
type of the value.

**What is the change**

For following system description,


```
module attributes {
dlti.target_system_spec = #dlti.target_system_spec<
"CPU": #dlti.target_device_spec<
#dlti.dl_entry<"max_vector_op_width", 64.0 : f32>>,
"GPU": #dlti.target_device_spec<
#dlti.dl_entry<"max_vector_op_width", 128 : ui32>>
>} {}
```

a user no longer needs to use `getDevicePropertyValueAsInt` for
retrieving GPU's `max_vector_op_width` and
`getDevicePropertyValueAsFloat` for retrieving CPU's
`max_vector_op_width`. Instead it can be done with a uniform API of
`getDevicePropertyValue`.

show more ...

Reimplementing target description concept using DLTI attribute (#92138)

and Interfaces. This is a newer implementation of PR
https://github.com/llvm/llvm-project/pull/85141 and
[RFC](https://discour

Reimplementing target description concept using DLTI attribute (#92138)

and Interfaces. This is a newer implementation of PR
https://github.com/llvm/llvm-project/pull/85141 and
[RFC](https://discourse.llvm.org/t/rfc-target-description-and-cost-model-in-mlir/76990)
by considering reviews and comments on the original PR.

As an example of attributes supported by this commit:

```
module attributes {
dlti.target_system_spec =
#dlti.target_device_spec<
#dlti.dl_entry<"dlti.device_id", 0: ui32>,
#dlti.dl_entry<"dlti.device_type", "CPU">,
#dlti.dl_entry<"dlti.L1_cache_size_in_bytes", 8192 : ui32>>,
#dlti.target_device_spec <
#dlti.dl_entry<"dlti.device_id", 1: ui32>,
#dlti.dl_entry<"dlti.device_type", "GPU">,
#dlti.dl_entry<"dlti.max_vector_op_width", 64 : ui32>>,
#dlti.target_device_spec <
#dlti.dl_entry<"dlti.device_id", 2: ui32>,
#dlti.dl_entry<"dlti.device_type", "XPU">>>
}
```

show more ...

[MLIR] Add endianness accessors to the data layout (#87347)

This commit extends the data layout subsystem with accessors for the
endianness. The implementation follows the structure implemented for

[MLIR] Add endianness accessors to the data layout (#87347)

This commit extends the data layout subsystem with accessors for the
endianness. The implementation follows the structure implemented for
alloca, global, and program memory spaces.

show more ...

[MLIR] Add index bitwidth to the DataLayout (#85927)

When importing from LLVM IR the data layout of all pointer types
contains an index bitwidth that should be used for index computations.
This re

[MLIR] Add index bitwidth to the DataLayout (#85927)

When importing from LLVM IR the data layout of all pointer types
contains an index bitwidth that should be used for index computations.
This revision adds a getter to the DataLayout that provides access to
the already stored bitwidth. The function returns an optional since only
pointer-like types have an index bitwidth. Querying the bitwidth of a
non-pointer type returns std::nullopt.

The new function works for the built-in Index type and, using a type
interface, for the LLVMPointerType.

show more ...

[mlir] Add global and program memory space handling to the data layout subsystem (#77367)

This patch is based on a previous PR https://reviews.llvm.org/D144657
that added alloca address space handl

[mlir] Add global and program memory space handling to the data layout subsystem (#77367)

This patch is based on a previous PR https://reviews.llvm.org/D144657
that added alloca address space handling to MLIR's DataLayout and DLTI
interface. This patch aims to add identical features to import and
access the global and program memory space through MLIR's
DataLayout/DLTI system.

show more ...

[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 `Abstrac

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

show more ...

[mlir] Fix a few more TypeSize::Fixed->TypeSize::getFixed following #72979.

[mlir] use TypeSize and uint64_t in DataLayout (#72874)

Data layout queries may be issued for types whose size exceeds the range
of 32-bit integer as well as for types that don't have a size known

[mlir] use TypeSize and uint64_t in DataLayout (#72874)

Data layout queries may be issued for types whose size exceeds the range
of 32-bit integer as well as for types that don't have a size known at
compile time, such as scalable vectors. Use best practices from LLVM IR
and adopt `llvm::TypeSize` for size-related queries and `uint64_t` for
alignment-related queries.

See #72678.

show more ...

[mlir] Fix typo in comments

Reviewed By: aartbik

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

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

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 patch updates all remaining uses of the deprecated functionality in
mlir/. This was done with clang-tidy as described below and further
modifications to GPUBase.td and OpenMPOpsInterfaces.td.

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:
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.

```
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
```

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

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] Add stack alignment to the data layout dialect.

The revision adds the stack alignment to the
data layout dialect and it extends the LLVM dialect
import and export to support the new data layo

[mlir] Add stack alignment to the data layout dialect.

The revision adds the stack alignment to the
data layout dialect and it extends the LLVM dialect
import and export to support the new data layout
entry.

One possible use case for the flag is the LLVM dialect
inliner. The LLVM inliner queries the flag to
determine if it is safe to update the alignment of an
existing alloca. We may want to perform the same
optimization inside of MLIR.

Reviewed By: Dinistro

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

show more ...

[mlir] Add alloca address space handling to the data layout subsystem

This patch adds alloca address space information to the data layout interface
and implementation in the DLTI dialect. This is ne

[mlir] Add alloca address space handling to the data layout subsystem

This patch adds alloca address space information to the data layout interface
and implementation in the DLTI dialect. This is needed for targets that use
separate address spaces for local/stack data.

Reviewed By: ftynse, krzysz00

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

show more ...

[ParseResult] Mark this as LLVM_NODISCARD (like LogicalResult) and fix issues.

There are a lot of cases where we accidentally ignored the result of some
parsing hook. Mark ParseResult as LLVM_NODIS

[ParseResult] Mark this as LLVM_NODISCARD (like LogicalResult) and fix issues.

There are a lot of cases where we accidentally ignored the result of some
parsing hook. Mark ParseResult as LLVM_NODISCARD just like ParseResult is.
This exposed some stuff to clean up, so do.

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

show more ...

[mlir] Refactoring dialect and test code to use parseCommaSeparatedList

Issue #55173

Reviewed By: lattner, rriddle

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

[mlir] Rework the implementation of TypeID

This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implici

[mlir] Rework the implementation of TypeID

This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implicit" fallback path to use the name of the type, instead of using
a static template variable (which breaks shared libraries). The major downside to this
is that it adds some additional initialization costs for the implicit path. Given the
use of type names for uniqueness in the fallback, we also no longer allow types
defined in anonymous namespaces to have an implicit TypeID. To simplify defining
an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro
was added to allow for explicitly defining a TypeID directly on an internal class.

To help identify when types are using the fallback, `-debug-only=typeid` can be
used to log which types are using implicit ids.

This change generally only requires changes to the test passes, which are all defined
in anonymous namespaces, and thus can't use the fallback any longer.

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

show more ...

Update more `parseSourceString()` call sites.

Change to non-deprecated function template (see D121075).

Reviewed By: rriddle

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

[mlir][NFC] Move Parser.h to Parser/

There is no reason for this file to be at the top-level, and
its current placement predates the Parser/ folder's existence.

Differential Revision: https://revie

[mlir][NFC] Move Parser.h to Parser/

There is no reason for this file to be at the top-level, and
its current placement predates the Parser/ folder's existence.

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

show more ...

Replace OwningModuleRef with OwningOpRef<ModuleOp>

This addresses a TODO in BuiltinOps.h.

Reviewed By: rriddle

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

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 ...

[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser.

The former is redundant because the later carries it as part of
its builder. Add a getContext() helper method to DialectAsmParser
to ma

[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser.

The former is redundant because the later carries it as part of
its builder. Add a getContext() helper method to DialectAsmParser
to make this more convenient, and stop passing the context around
explicitly. This simplifies ODS generated parser hooks for attrs
and types.

This resolves PR51985

Recommit 4b32f8bac4 after fixing a dependency.

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

show more ...

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 of
its builder. Add a getContext() helper method to DialectAsmParser
to ma

[ODS/AsmParser] Don't pass MLIRContext with DialectAsmParser.

The former is redundant because the later carries it as part of
its builder. Add a getContext() helper method to DialectAsmParser
to make this more convenient, and stop passing the context around
explicitly. This simplifies ODS generated parser hooks for attrs
and types.

This resolves PR51985

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

show more ...