[mlir] Make OpBuilder::createOperation to accept raw inputs

This provides a way to create an operation without manipulating
OperationState directly. This is useful for creating unregistered ops.

Re

[mlir] Make OpBuilder::createOperation to accept raw inputs

This provides a way to create an operation without manipulating
OperationState directly. This is useful for creating unregistered ops.

Reviewed By: rriddle, mehdi_amini

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

show more ...

[mlir] Make locations required when adding/creating block arguments

BlockArguments gained the ability to have locations attached a while ago, but they
have always been optional. This goes against th

[mlir] Make locations required when adding/creating block arguments

BlockArguments gained the ability to have locations attached a while ago, but they
have always been optional. This goes against the core tenant of MLIR where location
information is a requirement, so this commit updates the API to require locations.

Fixes #53279

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

show more ...

[mlir] Finish removing Identifier from the C++ API

There have been a few API pieces remaining to allow for a smooth transition for
downstream users, but these have been up for a few months now. Afte

[mlir] Finish removing Identifier from the C++ API

There have been a few API pieces remaining to allow for a smooth transition for
downstream users, but these have been up for a few months now. After this only
the C API will have reference to "Identifier", but those will be reworked in a followup.

The main updates are:
* Identifier -> StringAttr
* StringAttr::get requires the context as the first parameter
- i.e. `Identifier::get("...", ctx)` -> `StringAttr::get(ctx, "...")`

Reviewed By: mehdi_amini

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

show more ...

Fix more clang-tidy cleanups in mlir/ (NFC)

[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] Avoid folding in OpBuilder::tryFold when types change

This was missed when tightening fold restrictions in https://reviews.llvm.org/D95991.

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

[mlir] Avoid folding in OpBuilder::tryFold when types change

This was missed when tightening fold restrictions in https://reviews.llvm.org/D95991.

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

show more ...

[Builder] Eliminate the StringRef/StringAttr forms of getSymbolRefAttr.

The StringAttr version doesn't need a context, so we can just use the
existing `SymbolRefAttr::get` form. The StringRef versi

[Builder] Eliminate the StringRef/StringAttr forms of getSymbolRefAttr.

The StringAttr version doesn't need a context, so we can just use the
existing `SymbolRefAttr::get` form. The StringRef version isn't preferred
so we want to encourage people to use StringAttr.

There is an additional form of getSymbolRefAttr that takes a (SymbolTrait
implementing) operation. This should also be moved, but I'll do that as
a separate patch.

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

show more ...

[SymbolRefAttr] Revise SymbolRefAttr to hold a StringAttr.

SymbolRefAttr is fundamentally a base string plus a sequence
of nested references. Instead of storing the string data as
a copies StringRe

[SymbolRefAttr] Revise SymbolRefAttr to hold a StringAttr.

SymbolRefAttr is fundamentally a base string plus a sequence
of nested references. Instead of storing the string data as
a copies StringRef, store it as an already-uniqued StringAttr.

This makes a lot of things simpler and more efficient because:
1) references to the symbol are already stored as StringAttr's:
there is no need to copy the string data into MLIRContext
multiple times.
2) This allows pointer comparisons instead of string
comparisons (or redundant uniquing) within SymbolTable.cpp.
3) This allows SymbolTable to hold a DenseMap instead of a
StringMap (which again copies the string data and slows
lookup).

This is a moderately invasive patch, so I kept a lot of
compatibility APIs around. It would be nice to explore changing
getName() to return a StringAttr for example (right now you have
to use getNameAttr()), and eliminate things like the StringRef
version of getSymbol.

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

show more ...

[MLIR] Add `getI8Type` to `OpBuilder`

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

[Core] Add Twine support for StringAttr and Identifier. NFC.

This is both more efficient and more ergonomic than going
through an std::string, e.g. when using llvm::utostr and
in string concat cases

[Core] Add Twine support for StringAttr and Identifier. NFC.

This is both more efficient and more ergonomic than going
through an std::string, e.g. when using llvm::utostr and
in string concat cases.

Unfortunately we can't just overload ::get(). This causes an
ambiguity because both twine and stringref implicitly convert
from std::string.

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

show more ...

[IR] Add a Location to BlockArgument

This adds the ability to specify a location when creating BlockArguments.
Notably Value::getLoc() will return this correctly, which makes diagnostics
more precis

[IR] Add a Location to BlockArgument

This adds the ability to specify a location when creating BlockArguments.
Notably Value::getLoc() will return this correctly, which makes diagnostics
more precise (e.g. the example in test-legalize-type-conversion.mlir).

This is currently optional to avoid breaking any existing code - if
absent, the BlockArgument defaults to using the location of its enclosing
operation (preserving existing behavior).

The bulk of this change is plumbing location tracking through the parser
and printer to make sure it can round trip (in -mlir-print-debuginfo
mode). This is complete for generic operations, but requires manual
adoption for custom ops.

I added support for function-like ops to round trip their argument
locations - they print correctly, but when parsing the locations are
dropped on the floor. I intend to fix this, but it will require more
invasive plumbing through "function_like_impl" stuff so I think it
best to split it out to its own patch.

This is a reapply of the patch here: https://reviews.llvm.org/D102567
with an additional change: we now never defer block argument locations,
guaranteeing that we can round trip correctly.

This isn't required in all cases, but allows us to hill climb here and
works around unrelated bugs like https://bugs.llvm.org/show_bug.cgi?id=50451

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

show more ...

Revert "[IR] Add a Location to BlockArgument." and follow-on commit
"[mlir] Speed up Lexer::getEncodedSourceLocation"

This reverts commit 3043be9d2db4d0cdf079adb5e1bdff032405e941 and commit
861d69a5

Revert "[IR] Add a Location to BlockArgument." and follow-on commit
"[mlir] Speed up Lexer::getEncodedSourceLocation"

This reverts commit 3043be9d2db4d0cdf079adb5e1bdff032405e941 and commit
861d69a5259653f60d59795597493a7939b794fe.

This change resulted in printing textual MLIR that can't be parsed; see
review thread https://reviews.llvm.org/D102567 for details.

show more ...

[IR] Add a Location to BlockArgument.

This adds the ability to specify a location when creating BlockArguments.
Notably Value::getLoc() will return this correctly, which makes diagnostics
more preci

[IR] Add a Location to BlockArgument.

This adds the ability to specify a location when creating BlockArguments.
Notably Value::getLoc() will return this correctly, which makes diagnostics
more precise (e.g. the example in test-legalize-type-conversion.mlir).

This is currently optional to avoid breaking any existing code - if
absent, the BlockArgument defaults to using the location of its enclosing
operation (preserving existing behavior).

The bulk of this change is plumbing location tracking through the parser
and printer to make sure it can round trip (in -mlir-print-debuginfo
mode). This is complete for generic operations, but requires manual
adoption for custom ops.

I added support for function-like ops to round trip their argument
locations - they print correctly, but when parsing the locations are
dropped on the floor. I intend to fix this, but it will require more
invasive plumbing through "function_like_impl" stuff so I think it
best to split it out to its own patch.

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

show more ...

[mlir][linalg] lower index operations during linalg to vector lowering.

The patch extends the vectorization pass to lower linalg index operations to vector code. It allocates constant 1d vectors tha

[mlir][linalg] lower index operations during linalg to vector lowering.

The patch extends the vectorization pass to lower linalg index operations to vector code. It allocates constant 1d vectors that enumerate the indexes along the iteration dimensions and broadcasts/transposes these 1d vectors to the iteration space.

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

show more ...

[mlir] Simplify various pieces of code now that Identifier has access to the Context/Dialect

This also exposed a bug in Dialect loading where it was not correctly identifying identifiers that had th

[mlir] Simplify various pieces of code now that Identifier has access to the Context/Dialect

This also exposed a bug in Dialect loading where it was not correctly identifying identifiers that had the dialect namespace as a prefix.

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

show more ...

Revert "Revert "Reorder MLIRContext location in BuiltinAttributes.h""

This reverts commit 511dd4f4383b1c2873beac4dbea2df302f1f9d0c along with
a couple fixes.

Original message:
Now the context is th

Revert "Revert "Reorder MLIRContext location in BuiltinAttributes.h""

This reverts commit 511dd4f4383b1c2873beac4dbea2df302f1f9d0c along with
a couple fixes.

Original message:
Now the context is the first, rather than the last input.

This better matches the rest of the infrastructure and makes
it easier to move these types to being declaratively specified.

Phabricator: https://reviews.llvm.org/D96111

show more ...

Revert "Reorder MLIRContext location in BuiltinAttributes.h"

This reverts commit 7827753f9810e846fb702f3e8dcff0bfb37344e1.

Reorder MLIRContext location in BuiltinAttributes.h

Now the context is the first, rather than the last input.

This better matches the rest of the infrastructure and makes
it easier to move these ty

Reorder MLIRContext location in BuiltinAttributes.h

Now the context is the first, rather than the last input.

This better matches the rest of the infrastructure and makes
it easier to move these types to being declaratively specified.

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

show more ...

[mlir] Add better support for f80 and f128

Add builtin f80 and f128 following @schweitz proposition
https://llvm.discourse.group/t/rfc-adding-better-support-for-higher-precision-floating-point/2526/

[mlir] Add better support for f80 and f128

Add builtin f80 and f128 following @schweitz proposition
https://llvm.discourse.group/t/rfc-adding-better-support-for-higher-precision-floating-point/2526/5

Reviewed By: ftynse, rriddle

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

show more ...

[mlir][IR][NFC] Move context/location parameters of builtin Type::get methods to the start of the parameter list

This better matches the rest of the infrastructure, is much simpler, and makes it eas

[mlir][IR][NFC] Move context/location parameters of builtin Type::get methods to the start of the parameter list

This better matches the rest of the infrastructure, is much simpler, and makes it easier to move these types to being declaratively specified.

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

show more ...

[mlir][Attributes][NFC] Move all builtin Attribute classes to BuiltinAttributes.h

This mirrors the file structure of Types.

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

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

[mlir][IR] Remove references to BuiltinOps from IR/

There isn't a good reason for anything within IR to specifically reference any of the builtin operations. The only place that had a good reason in

[mlir][IR] Remove references to BuiltinOps from IR/

There isn't a good reason for anything within IR to specifically reference any of the builtin operations. The only place that had a good reason in the past was AsmPrinter, but the behavior there doesn't need to hardcode ModuleOp anymore.

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

show more ...

[mlir][BuiltinDialect] Resolve comments from D91571

* Move ops to a BuiltinOps.h
* Add file comments

[mlir][NFC] Remove references to Module.h and Function.h

These includes have been deprecated in favor of BuiltinDialect.h, which contains the definitions of ModuleOp and FuncOp.

Differential Revisi

[mlir][NFC] Remove references to Module.h and Function.h

These includes have been deprecated in favor of BuiltinDialect.h, which contains the definitions of ModuleOp and FuncOp.

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

show more ...