[MLIR][AMDGPU] Remove support for old llvm.amdgcn.buffer.* intrinsics (#93838)

They have been superseded by llvm.amdgcn.raw.buffer.* and
llvm.amdgcn.struct.buffer.*.

[NFC][mlir] Reorder `declarePromisedInterface()` operands (#86628)

Reorder the template operands of `declarePromisedInterface()` to match
`declarePromisedInterfaces()`.

[MLIR] Add ODS support for generating helpers for dialect (discardable) attributes (#77024)

This is a new ODS feature that allows dialects to define a list of
key/value pair representing an attribu

[MLIR] Add ODS support for generating helpers for dialect (discardable) attributes (#77024)

This is a new ODS feature that allows dialects to define a list of
key/value pair representing an attribute type and a name.
This will generate helper classes on the dialect to be able to
manage discardable attributes on operations in a type safe way.

For example the `test` dialect can define:

```
let discardableAttrs = (ins
"mlir::IntegerAttr":$discardable_attr_key,
);
```

And the following will be generated in the TestDialect class:

```
/// Helper to manage the discardable attribute `discardable_attr_key`.
class DiscardableAttrKeyAttrHelper {
::mlir::StringAttr name;
public:
static constexpr ::llvm::StringLiteral getNameStr() {
return "test.discardable_attr_key";
}
constexpr ::mlir::StringAttr getName() {
return name;
}

DiscardableAttrKeyAttrHelper(::mlir::MLIRContext *ctx)
: name(::mlir::StringAttr::get(ctx, getNameStr())) {}

mlir::IntegerAttr getAttr(::mlir::Operation *op) {
return op->getAttrOfType<mlir::IntegerAttr>(name);
}
void setAttr(::mlir::Operation *op, mlir::IntegerAttr val) {
op->setAttr(name, val);
}
bool isAttrPresent(::mlir::Operation *op) {
return op->hasAttrOfType<mlir::IntegerAttr>(name);
}
void removeAttr(::mlir::Operation *op) {
assert(op->hasAttrOfType<mlir::IntegerAttr>(name));
op->removeAttr(name);
}
};
DiscardableAttrKeyAttrHelper getDiscardableAttrKeyAttrHelper() {
return discardableAttrKeyAttrName;
}
```

User code having an instance of the TestDialect can then manipulate this
attribute on operation using:

```
auto helper = testDialect.getDiscardableAttrKeyAttrHelper();

helper.setAttr(op, value);
helper.isAttrPresent(op);
...
```

show more ...

[mlir] Fix some cmake dependencies in LLVMIR Dialect (#66956)

While looking into reducing needless interdependencies between upstream
MLIR dialects and passes, I discovered that the ROCDL Dialect

[mlir] Fix some cmake dependencies in LLVMIR Dialect (#66956)

While looking into reducing needless interdependencies between upstream
MLIR dialects and passes, I discovered that the ROCDL Dialect
redundantely uses links in `VectorToLLVM` conversion pass when it
actually requires just the LLVM Dialect. Furthermore, after a build
failure, I ran `ninja -t missingdeps` which revealed that the NVVM
Dialect depends on headers of the GPU dialect
(https://github.com/llvm/llvm-project/blob/211c9752c8200fbb3ff7be1f6aa98037901758ce/mlir/include/mlir/Dialect/LLVMIR/NVVMDialect.h#L18)
without stating so in CMake.
This causes flaky builds as it is not guaranteed that the header exists
prior to the dialect being compiled.

show more ...

[mlir] Extend the promise interface mechanism

This patch pairs a promised interface with the object (Op/Attr/Type/Dialect) requesting the promise, ie:
```
declarePromisedInterface<MyAttr, MyInterfac

[mlir] Extend the promise interface mechanism

This patch pairs a promised interface with the object (Op/Attr/Type/Dialect) requesting the promise, ie:
```
declarePromisedInterface<MyAttr, MyInterface>();
```
Allowing to make fine grained promises. It also adds a mechanism to query if `Op/Attr/Type` has an specific promise returning true if the promise is there or if an implementation has been added. Finally it adds a couple of `Attr|TypeConstraints` that can be used in ODS to query if the promise or an implementation is there.

This patch tries to solve 2 issues:
1. Different entities cannot use the same promise.
```
declarePromisedInterface<MyInterface>();
// Resolves a promise.
MyAttr1::attachInterface<MyInterface>(ctx);
// Doesn't resolves a promise, as the previous attachment removed the promise.
MyAttr2::attachInterface<MyInterface>(ctx);
```
2. Is not possible to query if a promise has been declared.

Reviewed By: mehdi_amini

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

show more ...

[mlir][ROCDL] Adds the ROCDL target attribute.

**For an explanation of these patches see D154153.**

Commit message:
This patch adds the ROCDL target attribute for serializing GPU modules into
strin

[mlir][ROCDL] Adds the ROCDL target attribute.

**For an explanation of these patches see D154153.**

Commit message:
This patch adds the ROCDL target attribute for serializing GPU modules into
strings containing HSAco.

Depends on D154117

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

show more ...

Revert "[mlir][ROCDL] Adds the ROCDL target attribute."

This reverts commit 6a0feb1503e21432e63d93b44357bad43f8026d1.

[mlir][ROCDL] Adds the ROCDL target attribute.

**For an explanation of these patches see D154153.**

Commit message:
This patch adds the ROCDL target attribute for serializing GPU modules into
strin

[mlir][ROCDL] Adds the ROCDL target attribute.

**For an explanation of these patches see D154153.**

Commit message:
This patch adds the ROCDL target attribute for serializing GPU modules into
strings containing HSAco.

Depends on D154117

Reviewed By: mehdi_amini, krzysz00

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

show more ...

[MLIR][AMDGPU][ROCDL] Adding raw.buffer.atomic.fmax/smax/umin support

This commit adds support for atomic fmax/smax/umin support
for AMDGPU dialect and the dependent dialects to allow such
a lowerin

[MLIR][AMDGPU][ROCDL] Adding raw.buffer.atomic.fmax/smax/umin support

This commit adds support for atomic fmax/smax/umin support
for AMDGPU dialect and the dependent dialects to allow such
a lowering.

Reviewed By: krzysz00

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

show more ...

[mlir] Update accessors to prefixed form (NFC)

Follow up from flipping dialects to both, flip accessor used to prefixed
variant ahead to flipping from _Both to _Prefixed. This just flips to
the acce

[mlir] Update accessors to prefixed form (NFC)

Follow up from flipping dialects to both, flip accessor used to prefixed
variant ahead to flipping from _Both to _Prefixed. This just flips to
the accessors introduced in the preceding change which are just prefixed
forms of the existing accessor changed from.

Mechanical change using helper script
https://github.com/jpienaar/llvm-project/blob/main/clang-tools-extra/clang-tidy/misc/AddGetterCheck.cpp and clang-format.

show more ...

[MLIR][AMDGPU] Add AMDGPU dialect, wrappers around raw buffer intrinsics

By analogy with the NVGPU dialect, introduce an AMDGPU dialect for
AMD-specific intrinsic wrappers.

The dialect initially in

[MLIR][AMDGPU] Add AMDGPU dialect, wrappers around raw buffer intrinsics

By analogy with the NVGPU dialect, introduce an AMDGPU dialect for
AMD-specific intrinsic wrappers.

The dialect initially includes wrappers around the raw buffer intrinsics.

On AMD GPUs, a memref can be converted to a "buffer descriptor" that
allows more precise control of memory access, such as by allowing for
out of bounds loads/stores to be replaced by 0/ignored without adding
additional conditional logic, which is important for performance.

The repository currently contains a limited conversion from
transfer_read/transfer_write to Mubuf intrinsics, which are an older,
deprecated intrinsic for the same functionality.

The new amdgpu.raw_buffer_* ops allow these operations to be used
explicitly and for including metadata such as whether the target
chipset is an RDNA chip or not (which impacts the interpretation of
some bits in the buffer descriptor), while still maintaining an
MLIR-like interface.

(This change also exposes the floating-point atomic add intrinsic.)

Reviewed By: ThomasRaoux

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

show more ...

[mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`

I am not sure about the meaning of Type in the name (was it meant be interpreted as Kind?), and given the importance and

[mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`

I am not sure about the meaning of Type in the name (was it meant be interpreted as Kind?), and given the importance and meaning of Type in the context of MLIR, its probably better to rename it. Given the comment in the source code, the suggestion in the GitHub issue and the final discussions in the review, this patch renames the OperandType to UnresolvedOperand.

Fixes https://github.com/llvm/llvm-project/issues/54446

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

show more ...

[mlir] Update uses of `parser`/`printer` ODS op field to `hasCustomAssemblyFormat`

The parser/printer fields are deprecated and in the process of being removed.

[mlir] Convert NamedAttribute to be a class

NamedAttribute is currently represented as an std::pair, but this
creates an extremely clunky .first/.second API. This commit
converts it to a class, with

[mlir] Convert NamedAttribute to be a class

NamedAttribute is currently represented as an std::pair, but this
creates an extremely clunky .first/.second API. This commit
converts 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

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

[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

show more ...

[mlir] add verifiers for NVVM and ROCDL kernel attributes

Make sure they can only be attached to LLVM functions as a result of converting
GPU functions to the LLVM Dialect.

[mlir] use built-in vector types instead of LLVM dialect types when possible

Continue the convergence between LLVM dialect and built-in types by using the
built-in vector type whenever possible, tha

[mlir] use built-in vector types instead of LLVM dialect types when possible

Continue the convergence between LLVM dialect and built-in types by using the
built-in vector type whenever possible, that is for fixed vectors of built-in
integers and built-in floats. LLVM dialect vector type is still in use for
pointers, less frequent floating point types that do not have a built-in
equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class
has been removed in favor of free functions capable of inspecting both built-in
and LLVM dialect vector types: `LLVM::getVectorElementType`,
`LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is
necessary to design an implemented the extensions to built-in types so as to
remove the `LLVMFixedVectorType` entirely.

Note that the default output format for the built-in vectors does not have
whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the
LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This
required changing the FileCheck patterns in several tests.

Reviewed By: mehdi_amini, silvas

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

show more ...

[mlir] replace LLVMIntegerType with built-in integer type

The LLVM dialect type system has been closed until now, i.e. did not support
types from other dialects inside containers. While this has had

[mlir] replace LLVMIntegerType with built-in integer type

The LLVM dialect type system has been closed until now, i.e. did not support
types from other dialects inside containers. While this has had obvious
benefits of deriving from a common base class, it has led to some simple types
being almost identical with the built-in types, namely integer and floating
point types. This in turn has led to a lot of larger-scale complexity: simple
types must still be converted, numerous operations that correspond to LLVM IR
intrinsics are replicated to produce versions operating on either LLVM dialect
or built-in types leading to quasi-duplicate dialects, lowering to the LLVM
dialect is essentially required to be one-shot because of type conversion, etc.
In this light, it is reasonable to trade off some local complexity in the
internal implementation of LLVM dialect types for removing larger-scale system
complexity. Previous commits to the LLVM dialect type system have adapted the
API to support types from other dialects.

Replace LLVMIntegerType with the built-in IntegerType plus additional checks
that such types are signless (these are isolated in a utility function that
replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility
to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice.

Reviewed By: mehdi_amini, silvas, antiagainst

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

show more ...

[mlir] Remove static constructors from LLVMType

LLVMType contains numerous static constructors that were initially introduced
for API compatibility with LLVM. Most of these merely forward to argumen

[mlir] Remove static constructors from LLVMType

LLVMType contains numerous static constructors that were initially introduced
for API compatibility with LLVM. Most of these merely forward to arguments to
`SpecificType::get` (MLIR defines classes for all types, unlike LLVM IR), while
some introduce subtle semantics differences due to different modeling of MLIR
types (e.g., structs are not auto-renamed in case of conflicts). Furthermore,
these constructors don't match MLIR idioms and actively prevent us from making
the LLVM dialect type system more open. Remove them and use `SpecificType::get`
instead.

Depends On D93680

Reviewed By: mehdi_amini

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

show more ...

[mlir][Types][NFC] Move all of the builtin Type classes to BuiltinTypes.h

This is part of a larger refactoring the better congregates the builtin structures under the BuiltinDialect. This also remov

[mlir][Types][NFC] Move all of the builtin Type classes to BuiltinTypes.h

This is part of a larger refactoring the better congregates the builtin structures under the BuiltinDialect. This also removes the problematic "standard" naming that clashes with the "standard" dialect, which is not defined within IR/. A temporary forward is placed in StandardTypes.h to allow time for downstream users to replaced references.

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

show more ...

Make namespace handling uniform across dialect backends.

Now backends spell out which namespace they want to be in, instead of relying on
clients #including them inside already-opened namespaces. Th

Make namespace handling uniform across dialect backends.

Now backends spell out which namespace they want to be in, instead of relying on
clients #including them inside already-opened namespaces. This also means that
cppNamespaces should be fully qualified, and there's no implicit "::mlir::"
prepended to them anymore.

Reviewed By: mehdi_amini

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

show more ...

Revisit Dialect registration: require and store a TypeID on dialects

This patch moves the registration to a method in the MLIRContext: getOrCreateDialect<ConcreteDialect>()

This method requires dia

Revisit Dialect registration: require and store a TypeID on dialects

This patch moves the registration to a method in the MLIRContext: getOrCreateDialect<ConcreteDialect>()

This method requires dialect to provide a static getDialectNamespace()
and store a TypeID on the Dialect itself, which allows to lazyily
create a dialect when not yet loaded in the context.
As a side effect, it means that duplicated registration of the same
dialect is not an issue anymore.

To limit the boilerplate, TableGen dialect generation is modified to
emit the constructor entirely and invoke separately a "init()" method
that the user implements.

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

show more ...