[mlir] Fix conflict of user defined reserved functions with internal prototypes (#123378)

On lowering from `memref` to LLVM, `malloc` and other intrinsic
functions from `libc` will be declared in t

[mlir] Fix conflict of user defined reserved functions with internal prototypes (#123378)

On lowering from `memref` to LLVM, `malloc` and other intrinsic
functions from `libc` will be declared in the current module. User's
redefinition of these reserved functions will poison the internal
analysis with wrong prototype. This patch adds assertion on the found
function's type and reports if it mismatch with the intended type.

Related to #120950


---------

Co-authored-by: Luohao Wang <Luohaothu@users.noreply.github.com>

show more ...

[mlir][GPU] Add NVVM-specific `cf.assert` lowering (#120431)

This commit add an NVIDIA-specific lowering of `cf.assert` to to
`__assertfail`.

Note: `getUniqueFormatGlobalName`, `getOrCreateForma

[mlir][GPU] Add NVVM-specific `cf.assert` lowering (#120431)

This commit add an NVIDIA-specific lowering of `cf.assert` to to
`__assertfail`.

Note: `getUniqueFormatGlobalName`, `getOrCreateFormatStringConstant` and
`getOrDefineFunction` are moved to `GPUOpsLowering.h`, so that they can
be reused.

show more ...

[mlir][CF] Split `cf-to-llvm` from `func-to-llvm` (#120580)

Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes
https://github.com/llvm/llvm-project/issues/70982.

This commit ch

[mlir][CF] Split `cf-to-llvm` from `func-to-llvm` (#120580)

Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes
https://github.com/llvm/llvm-project/issues/70982.

This commit changes the way how `func.func` ops are lowered to LLVM.
Previously, the signature of the entire region (i.e., entry block and
all other blocks in the `func.func` op) was converted as part of the
`func.func` lowering pattern.

Now, only the entry block is converted. The remaining block signatures
are converted together with `cf.br` and `cf.cond_br` as part of
`cf-to-llvm`. All unstructured control flow is not converted as part of
a single pass (`cf-to-llvm`). `func-to-llvm` no longer deals with
unstructured control flow.

Also add more test cases for control flow dialect ops.

Note: This PR is in preparation of #120431, which adds an additional
GPU-specific lowering for `cf.assert`. This was a problem because
`cf.assert` used to be converted as part of `func-to-llvm`.

Note for LLVM integration: If you see failures, add
`-convert-cf-to-llvm` to your pass pipeline.

show more ...

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

[MLIR][ControlFlowToLLVM] Remove typed pointer support (#70733)

This commit removes the support for lowering ControlFlow to LLVM dialect
with typed pointers. Typed pointers have been deprecated for

[MLIR][ControlFlowToLLVM] Remove typed pointer support (#70733)

This commit removes the support for lowering ControlFlow to LLVM dialect
with typed pointers. Typed pointers have been deprecated for a while now
and it's planned to soon remove them from the LLVM dialect.

Related PSA:
https://discourse.llvm.org/t/psa-removal-of-typed-pointers-from-the-llvm-dialect/74502

show more ...

[mlir][VectorOps] Support string literals in `vector.print` (#68695)

Printing strings within integration tests is currently quite annoyingly
verbose, and can't be tucked into shared helpers as the

[mlir][VectorOps] Support string literals in `vector.print` (#68695)

Printing strings within integration tests is currently quite annoyingly
verbose, and can't be tucked into shared helpers as the types depend on
the length of the string:

```
llvm.mlir.global internal constant @hello_world("Hello, World!\0")

func.func @entry() {
%0 = llvm.mlir.addressof @hello_world : !llvm.ptr<array<14 x i8>>
%1 = llvm.mlir.constant(0 : index) : i64
%2 = llvm.getelementptr %0[%1, %1]
: (!llvm.ptr<array<14 x i8>>, i64, i64) -> !llvm.ptr<i8>
llvm.call @printCString(%2) : (!llvm.ptr<i8>) -> ()
return
}
```

So this patch adds a simple extension to `vector.print` to simplify
this:
```
func.func @entry() {
// Print a vector of characters ;)
vector.print str "Hello, World!"
return
}
```

Most of the logic for this is now shared with `cf.assert` which already
does something similar.

Depends on #68694

show more ...

[mlir][Conversion] Store const type converter in ConversionPattern

ConversionPatterns do not (and should not) modify the type converter that they are using.

* Make `ConversionPattern::typeConverter

[mlir][Conversion] Store const type converter in ConversionPattern

ConversionPatterns do not (and should not) modify the type converter that they are using.

* Make `ConversionPattern::typeConverter` const.
* Make member functions of the `LLVMTypeConverter` const.
* Conversion patterns take a const type converter.
* Various helper functions (that are called from patterns) now also take a const type converter.

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

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

Revert "[mlir][conversion] NFC - Relax convert-cf-to-llvm and finalize-memref-to-llvm to also work on non-builtin module ops"

This reverts commit cc6b8d8077699916728053dfa760e69e146271cb.

Seems to

Revert "[mlir][conversion] NFC - Relax convert-cf-to-llvm and finalize-memref-to-llvm to also work on non-builtin module ops"

This reverts commit cc6b8d8077699916728053dfa760e69e146271cb.

Seems to have been committed accidentally.

show more ...

[mlir][conversion] NFC - Relax convert-cf-to-llvm and finalize-memref-to-llvm to also work on non-builtin module ops

This is a prerequisite for unentangling LowerGpuOpsToNVVMOps which explicitly pop

[mlir][conversion] NFC - Relax convert-cf-to-llvm and finalize-memref-to-llvm to also work on non-builtin module ops

This is a prerequisite for unentangling LowerGpuOpsToNVVMOps which explicitly populates its conversion with
`populateControlFlowToLLVMConversionPatterns` and `populateFinalizeMemRefToLLVMConversionPatterns`.

However those patterns cannot be generally added to a pass anchored on a non-ModuleOp.

Instead, LowerGpuOpsToNVVMOps should stop including the world, in a future commit.

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

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][cf] Add support for opaque pointers to ControlFlowToLLVM lowering

Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179

This is a

[mlir][cf] Add support for opaque pointers to ControlFlowToLLVM lowering

Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179

This is a very simple patch since there is only one use of pointers types in `cf.assert` that has to be changed. Pointer types are conditionally created with element types and the GEP had to be adjusted to use the array type as base type.

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

show more ...

[mlir][MemRef] Add option to `-finalize-memref-to-llvm` to emit opaque pointers

This is the first patch in a series of patches part of this RFC: https://discourse.llvm.org/t/rfc-switching-the-llvm-d

[mlir][MemRef] Add option to `-finalize-memref-to-llvm` to emit opaque pointers

This is the first patch in a series of patches part of this RFC: https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179

This patch adds the ability to lower the memref dialect to the LLVM Dialect with the use of opaque pointers instead of typed pointers. The latter are being phased out of LLVM and this patch is part of an effort to phase them out of MLIR as well. To do this, we'll need to support both typed and opaque pointers in lowering passes, to allow downstream projects to change without breakage.

The gist of changes required to change a conversion pass are:
* Change any `LLVM::LLVMPointerType::get` calls to NOT use an element type if opaque pointers are to be used.
* Use the `build` method of `llvm.load` with the explicit result type. Since the pointer does not have an element type anymore it has to be specified explicitly.
* Use the `build` method of `llvm.getelementptr` with the explicit `basePtrType`. Ditto to above, we have to now specify what the element type is so that GEP can do its indexing calculations
* Use the `build` method of `llvm.alloca` with the explicit `elementType`. Ditto to the above, alloca needs to know how many bytes to allocate through the element type.
* Get rid of any `llvm.bitcast`s
* Adapt the tests to the above. Note that `llvm.store` changes syntax as well when using opaque pointers

I'd like to note that the 3 `build` method changes work for both opaque and typed pointers, so unconditionally using the explicit element type form is always correct.

For the testsuite a practical approach suggested by @ftynse was taken: I created a separate test file for testing the typed pointer lowering of Ops. This mostly comes down to checking that bitcasts have been created at the appropiate places, since these are required for typed pointer support.

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

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][cf] Print message in cf.assert to LLVM lowering

The assert message was previously ignored. The lowered IR now calls `puts` it in case of a failed assertion.

Differential Revision: https://re

[mlir][cf] Print message in cf.assert to LLVM lowering

The assert message was previously ignored. The lowered IR now calls `puts` it in case of a failed assertion.

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

show more ...

[mlir] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[mlir] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
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 ...

[mlir][cf-to-llvm] Fix error message

[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] Only conditionally lower CF branching ops to LLVM

Previously cf.br cf.cond_br and cf.switch always lowered to their LLVM
equivalents. These ops are all ops that take in some values of given
t

[mlir] Only conditionally lower CF branching ops to LLVM

Previously cf.br cf.cond_br and cf.switch always lowered to their LLVM
equivalents. These ops are all ops that take in some values of given
types and jump to other blocks with argument lists of the same types. If
the types are not the same, a verification failure will later occur. This led
to confusions, as everything works when func->llvm and cf->llvm lowering
both occur because func->llvm updates the blocks and argument lists
while cf->llvm updates the branching ops. Without func->llvm though,
there will potentially be a type mismatch.

This change now only lowers the CF ops if they will later pass
verification. This is possible because the parent op and its blocks will
be updated before the contained branching ops, so they can test their
new operand types against the types of the blocks they jump to.

Another plan was to have func->llvm only update the entry block
signature and to allow cf->llvm to update all other blocks, but this had
2 problems:
1. This would create a FuncOp lowering in cf->llvm lowering which is
awkward
2. This new pattern would only be applied if the containing FuncOp is
marked invalid. This is infeasible with the shared LLVM type
conversion/target infrastructure.

See previous discussions at
https://discourse.llvm.org/t/lowering-cf-to-llvm/63863 and
https://github.com/llvm/llvm-project/issues/55301

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

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] Split out a new ControlFlow dialect from Standard

This dialect is intended to model lower level/branch based control-flow constructs. The initial set
of operations are: AssertOp, BranchOp, Co

[mlir] Split out a new ControlFlow dialect from Standard

This dialect is intended to model lower level/branch based control-flow constructs. The initial set
of operations are: AssertOp, BranchOp, CondBranchOp, SwitchOp; all split out from the current
standard dialect.

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

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

show more ...