[mlir][NFC] Mark type converter in `populate...` functions as `const` (#111250)

This commit marks the type converter in `populate...` functions as
`const`. This is useful for debugging.

Patterns

[mlir][NFC] Mark type converter in `populate...` functions as `const` (#111250)

This commit marks the type converter in `populate...` functions as
`const`. This is useful for debugging.

Patterns already take a `const` type converter. However, some
`populate...` functions do not only add new patterns, but also add
additional type conversion rules. That makes it difficult to find the
place where a type conversion was added in the code base. With this
change, all `populate...` functions that only populate pattern now have
a `const` type converter. Programmers can then conclude from the
function signature that these functions do not register any new type
conversion rules.

Also some minor cleanups around the 1:N dialect conversion
infrastructure, which did not always pass the type converter as a
`const` object internally.

show more ...

Apply clang-tidy fixes for llvm-include-order in ComplexToLLVM.cpp (NFC)

[mlir][complex] Initial support for FastMath flag when converting to LLVM

This change contains the initial support of FastMath flag in complex dialect. Similar to what we did in [Arith dialect](http

[mlir][complex] Initial support for FastMath flag when converting to LLVM

This change contains the initial support of FastMath flag in complex dialect. Similar to what we did in [Arith dialect](https://reviews.llvm.org/rGb56e65d31825fe4a1ae02fdcbad58bb7993d63a7), `fastmath` attributes in the complex dialect are directly mapped to the corresponding LLVM fastmath flags.

In this diff,

- Definition of FastMathAttr as a custom attribute in the Complex dialect that inherits from the EnumAttr class.
- Definition of ComplexFastMathInterface, which is an interface that is implemented by operations that have a complex::fastmath attribute.
- Declaration of a default-valued fastmath attribute for unary and arithmetic operations in the Complex dialect.
- Conversion code to lower arithmetic fastmath flags to LLVM fastmath flags

NOT in this diff (but planned and progressively implemented):

- Documentation of flag meanings
- Support the fastmath flag conversion to Arith dialect
- Folding/rewrite implementations that are enabled by fastmath flags (although it's the original motivation to support the flag)

RFC: https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981

Reviewed By: kiranchandramohan

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

show more ...

[mlir][Conversion] Re-submit: Implement ConvertToLLVMPatternInterface (1)

This is a resubmit of the original D157391 change, which was reverted
because it needed special handling for the async diale

[mlir][Conversion] Re-submit: Implement ConvertToLLVMPatternInterface (1)

This is a resubmit of the original D157391 change, which was reverted
because it needed special handling for the async dialect. (I removed it
from this change.)

Implement ConvertToLLVMPatternInterface for more dialects: arith,
complex, cf.

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

show more ...

Revert "[mlir][Conversion] Implement ConvertToLLVMPatternInterface (1)"

This reverts commit 52aa6bd3fd6f48f583beaadcbb53edc0f3def4a1.

async-to-llvm needs special handling as it uses the type conver

Revert "[mlir][Conversion] Implement ConvertToLLVMPatternInterface (1)"

This reverts commit 52aa6bd3fd6f48f583beaadcbb53edc0f3def4a1.

async-to-llvm needs special handling as it uses the type converter in a
different way.

show more ...

[mlir][Conversion] Implement ConvertToLLVMPatternInterface (1)

Implement ConvertToLLVMPatternInterface for more dialects: arith, async,
complex, cf.

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

[mlir][Conversion] Implement ConvertToLLVMPatternInterface (1)

Implement ConvertToLLVMPatternInterface for more dialects: arith, async,
complex, cf.

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

show more ...

[mlir] Port Conversion Passes to LLVM to use TableGen generated constructors and options

See https://github.com/llvm/llvm-project/issues/57475 for more context.

Using auto-generated constructors an

[mlir] Port Conversion Passes to LLVM to use TableGen generated constructors and options

See https://github.com/llvm/llvm-project/issues/57475 for more context.

Using auto-generated constructors and options has significant advantages:
* It forces a uniform style and expectation for consuming a pass
* It allows to very easily add, remove or change options to a pass by simply making the changes in TableGen
* Its less code

This patch in particular ports all the conversion passes which lower to LLVM to use the auto generated constructors and options. For the most part, care was taken so that auto generated constructor functions have the same name as they previously did. Only following slight breaking changes (which I consider as worth the churn) have been made:
* `mlir::cf::createConvertControlFlowToLLVMPass` has been moved to the `mlir` namespace. This is consistent with basically all conversion passes
* `createGpuToLLVMConversionPass` now takes a proper options struct array for its pass options. The pass options are now also autogenerated.
* `LowerVectorToLLVMOptions` has been replaced by the autogenerated `ConvertVectorToLLVMPassOptions` which is automatically kept up to date by TableGen
* I had to move one function in the GPU to LLVM lowering as it is used as default value for an option.
* All passes that previously returned `unique_ptr<OperationPass<...>>` now simply return `unique_ptr<Pass>`

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

show more ...

[mlir][arith] Initial support for fastmath flag attributes in the Arithmetic dialect (v2)

This diff adds initial (partial) support for "fastmath" attributes for floating
point operations in the arit

[mlir][arith] Initial support for fastmath flag attributes in the Arithmetic dialect (v2)

This diff adds initial (partial) support for "fastmath" attributes for floating
point operations in the arithmetic dialect. The "fastmath" attributes are
implemented using a default-valued bit enum. The defined flags currently mirror
the fastmath flags in the LLVM dialect (and in LLVM itself). Extending the
set of flags (if necessary) is left as a future task.

In this diff:
- Definition of FastMathAttr as a custom attribute in the Arithmetic dialect
that inherits from the EnumAttr class.
- Definition of ArithFastMathInterface, which is an interface that is
implemented by operations that have an arith::fastmath attribute.
- Declaration of a default-valued fastmath attribute for unary and (some) binary
floating point operations in the Arithmetic dialect.
- Conversion code to lower arithmetic fastmath flags to LLVM fastmath flags

NOT in this diff (but planned or currently in progress):
- Documentation of flag meanings
- Addition of FastMathAttr attributes to other dialects that might lower to the
Arithmetic dialect (e.g. Math and Complex)
- Folding/rewrite implementations that are enabled by fastmath flags
- Specification of fastmath values from Python bindings (pending other in-
progress diffs)

Reviewed By: mehdi_amini, vzakhari

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

show more ...

[mlir][LLVMIR] Update LLVMIR fastmath to use EnumAttr tblgen classes

This diff updates the `fastmath` attribute in the LLVMIR dialect to use `tblgen`
classes that were developed after the initial LL

[mlir][LLVMIR] Update LLVMIR fastmath to use EnumAttr tblgen classes

This diff updates the `fastmath` attribute in the LLVMIR dialect to use `tblgen`
classes that were developed after the initial LLVMIR `fastmath` implementation.
Using the `EnumAttr` `tblgen` classes brings the LLVMIR `fastmath` attribute in
line with other dialects, and eliminates some of the custom printing and parsing
code in the LLVMIR dialect.

Subsequent commits will further reduce the custom processing code for the LLVMIR
`fastmath` attribute by unifying printing/parsing functionality between the
LLVMIR and `arith` `fastmath` attributes. (The actual attributes will remain
separate, but the printing and parsing will be made generic, and will be usable
by other dialects/attributes.)

Reviewed By: ftynse

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

show more ...

[mlir][arith] Change dialect name from Arithmetic to Arith

Suggested by @lattner in https://discourse.llvm.org/t/rfc-define-precise-arith-semantics/65507/22.

Tested with:
`ninja check-mlir check-ml

[mlir][arith] Change dialect name from Arithmetic to Arith

Suggested by @lattner in https://discourse.llvm.org/t/rfc-define-precise-arith-semantics/65507/22.

Tested with:
`ninja check-mlir check-mlir-integration check-mlir-mlir-spirv-cpu-runner check-mlir-mlir-vulkan-runner check-mlir-examples`

and `bazel build --config=generic_clang @llvm-project//mlir:all`.

Reviewed By: lattner, Mogball, rriddle, jpienaar, mehdi_amini

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

show more ...

[MLIR] Update pass declarations to new autogenerated files

The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow drop

[MLIR] Update pass declarations to new autogenerated files

The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure.

Reviewed By: mehdi_amini, rriddle

Differential Review: https://reviews.llvm.org/D132838

show more ...

Revert "[MLIR] Update pass declarations to new autogenerated files"

This reverts commit 2be8af8f0e0780901213b6fd3013a5268ddc3359.

[MLIR] Update pass declarations to new autogenerated files

The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow drop

[MLIR] Update pass declarations to new autogenerated files

The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure.

Reviewed By: mehdi_amini, rriddle

Differential Review: https://reviews.llvm.org/D132838

show more ...

[mlir] Change ComplexToLLVM to be a generic pass

It is currently a module pass, but shouldn't be. All of the patterns
are local conversions, and don't require anything about
functions/modules.

Diff

[mlir] Change ComplexToLLVM to be a generic pass

It is currently a module pass, but shouldn't be. All of the patterns
are local conversions, and don't require anything about
functions/modules.

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

show more ...

[mlir] Trim a huge number of unnecessary dependencies on the Func dialect

The Func has a large number of legacy dependencies carried over from the old
Standard dialect, which was pervasive and conta

[mlir] Trim a huge number of unnecessary dependencies on the Func dialect

The Func has a large number of legacy dependencies carried over from the old
Standard dialect, which was pervasive and contained a large number of varied
operations. With the split of the standard dialect and its demise, a lot of lingering
dead dependencies have survived to the Func dialect. This commit removes a
large majority of then, greatly reducing the dependence surface area of the
Func dialect.

show more ...

[mlir] Rename the Standard dialect to the Func dialect

The last remaining operations in the standard dialect all revolve around
FuncOp/function related constructs. This patch simply handles the init

[mlir] Rename the Standard dialect to the Func dialect

The last remaining operations in the standard dialect all revolve around
FuncOp/function related constructs. This patch simply handles the initial
renaming (which by itself is already huge), but there are a large number
of cleanups unlocked/necessary afterwards:

* Removing a bunch of unnecessary dependencies on Func
* Cleaning up the From/ToStandard conversion passes
* Preparing for the move of FuncOp to the Func dialect

See the discussion at https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061

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

show more ...

[mlir][complex] Lower complex.constant to LLVM

This fixes a regression from 480cd4cb8560532e544fc0c234749912dde759c6

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

[mlir] Switching accessors to prefixed form (NFC)

Makes eventual prefixing flag flip smaller change.

[MLIR] Replace std ops with arith dialect ops

Precursor: https://reviews.llvm.org/D110200

Removed redundant ops from the standard dialect that were moved to the
`arith` or `math` dialects.

Renamed

[MLIR] Replace std ops with arith dialect ops

Precursor: https://reviews.llvm.org/D110200

Removed redundant ops from the standard dialect that were moved to the
`arith` or `math` dialects.

Renamed all instances of operations in the codebase and in tests.

Reviewed By: rriddle, jpienaar

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

show more ...

[mlir:OpConversion] Remove the remaing usages of the deprecated matchAndRewrite methods

This commits updates the remaining usages of the ArrayRef<Value> based
matchAndRewrite/rewrite methods in favo

[mlir:OpConversion] Remove the remaing usages of the deprecated matchAndRewrite methods

This commits updates the remaining usages of the ArrayRef<Value> based
matchAndRewrite/rewrite methods in favor of the new OpAdaptor
overload.

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

show more ...

[mlir] replace llvm.mlir.cast with unrealized_conversion_cast

The dialect-specific cast between builtin (ex-standard) types and LLVM
dialect types was introduced long time before built-in support fo

[mlir] replace llvm.mlir.cast with unrealized_conversion_cast

The dialect-specific cast between builtin (ex-standard) types and LLVM
dialect types was introduced long time before built-in support for
unrealized_conversion_cast. It has a similar purpose, but is restricted
to compatible builtin and LLVM dialect types, which may hamper
progressive lowering and composition with types from other dialects.
Replace llvm.mlir.cast with unrealized_conversion_cast, and drop the
operation that became unnecessary.

Also make unrealized_conversion_cast legal by default in
LLVMConversionTarget as the majority of convesions using it are partial
conversions that actually want the casts to persist in the IR. The
standard-to-llvm conversion, which is still expected to run last, cleans
up the remaining casts standard-to-llvm conversion, which is still
expected to run last, cleans up the remaining casts

Reviewed By: nicolasvasilache

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

show more ...

[mlir] factor memref-to-llvm lowering out of std-to-llvm

After the MemRef has been split out of the Standard dialect, the
conversion to the LLVM dialect remained as a huge monolithic pass.
This is u

[mlir] factor memref-to-llvm lowering out of std-to-llvm

After the MemRef has been split out of the Standard dialect, the
conversion to the LLVM dialect remained as a huge monolithic pass.
This is undesirable for the same complexity management reasons as having
a huge Standard dialect itself, and is even more confusing given the
existence of a separate dialect. Extract the conversion of the MemRef
dialect operations to LLVM into a separate library and a separate
conversion pass.

Reviewed By: herhut, silvas

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

show more ...

[mlir] factor out common parts of the converstion to the LLVM dialect

"Standard-to-LLVM" conversion is one of the oldest passes in existence. It has
become quite large due to the size of the Standar

[mlir] factor out common parts of the converstion to the LLVM dialect

"Standard-to-LLVM" conversion is one of the oldest passes in existence. It has
become quite large due to the size of the Standard dialect itself, which is
being split into multiple smaller dialects. Furthermore, several conversion
features are useful for any dialect that is being converted to the LLVM
dialect, which, without this refactoring, creates a dependency from those
conversions to the "standard-to-llvm" one.

Put several of the reusable utilities from this conversion to a separate
library, namely:
- type converter from builtin to LLVM dialect types;
- utility for building and accessing values of LLVM structure type;
- utility for building and accessing values that represent memref in the LLVM
dialect;
- lowering options applicable everywhere.

Additionally, remove the type wrapping/unwrapping notion from the type
converter that is no longer relevant since LLVM types has been reimplemented as
first-class MLIR types.

Reviewed By: pifon2a

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

show more ...

[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFC

This doesn't change APIs, this just cleans up the many in-tree uses of these
names to use t

[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFC

This doesn't change APIs, this just cleans up the many in-tree uses of these
names to use the new preferred names. We'll keep the old names around for a
couple weeks to help transitions.

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

show more ...

Change OwningRewritePatternList to carry an MLIRContext with it.

This updates the codebase to pass the context when creating an instance of
OwningRewritePatternList, and starts removing extraneous M

Change OwningRewritePatternList to carry an MLIRContext with it.

This updates the codebase to pass the context when creating an instance of
OwningRewritePatternList, and starts removing extraneous MLIRContext
parameters. There are many many more to be removed.

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

show more ...