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

NFC: resolve TODO in LLVM dialect conversions (#91497)

Relaxes restriction that certain public utility functions only apply
to the builtin ModuleOp.

[MLIR][LLVM] Remove typed pointer conversion utils (#71169)

This commit removes the no longer required type pointer helpers from the
LLVM dialect conversion utils. Typed pointers have been deprecat

[MLIR][LLVM] Remove typed pointer conversion utils (#71169)

This commit removes the no longer required type pointer helpers from the
LLVM dialect conversion utils. 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][vector] add support for printing f16 and bf16

Love or hate it, but the vector.print operation was the very
first operation that actually made "end-to-end" CHECK integration
testing possible f

[mlir][vector] add support for printing f16 and bf16

Love or hate it, but the vector.print operation was the very
first operation that actually made "end-to-end" CHECK integration
testing possible for MLIR. This revision adds support for
the -until recently- less common but important floating-point
types f16 and bf16.

This will become useful for accelerator specific testing (e.g. NVidia GPUs)

Reviewed By: wrengr

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

show more ...

[mlir][llvm] Add isVarArg flag to lookupOrCreateFn.

The function is a helper for looking up a function by name or creating
it if it doesn't exist. The arguments allow to specify the signature of
the

[mlir][llvm] Add isVarArg flag to lookupOrCreateFn.

The function is a helper for looking up a function by name or creating
it if it doesn't exist. The arguments allow to specify the signature of
the function, if it needs to be created, but do not expose the varArg
parameter of LLVMFunctionType. This patch exposes adds an optional
parameter with a default value of false such that existing usage
continue to work as before.

Reviewed By: springerm

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

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

[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][LLVMIR] Clean up the definitions of ReturnOp/CallOp

[MLIR] Rename the generic LLVM allocation and deallocation functions

The generic allocation and deallocation instructions, which are optionally used during the MemRef -> LLVM conversion, should have

[MLIR] Rename the generic LLVM allocation and deallocation functions

The generic allocation and deallocation instructions, which are optionally used during the MemRef -> LLVM conversion, should have a name that is specifically bound to their origin, that is the conversion pass itself.

Reviewed By: silvas

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

show more ...

[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functions

When converted to the LLVM dialect, the memref.alloc and memref.free operations were generating calls to hardcoded 'malloc' and 'free' f

[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functions

When converted to the LLVM dialect, the memref.alloc and memref.free operations were generating calls to hardcoded 'malloc' and 'free' functions. This didn't leave any freedom to users to provide their custom implementation. Those operations now convert into calls to '_mlir_alloc' and '_mlir_free' functions, which have also been implemented into the runtime support library as wrappers to 'malloc' and 'free'. The same has been done for the 'aligned_alloc' function.

Reviewed By: ftynse

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

show more ...

Revert "[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functions"

This reverts commit 3e21fb616d9a1b29bf9d1a1ba484add633d6d5b3.

A lot of integration tests are failing on the bot.

[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functions

When converted to the LLVM dialect, the memref.alloc and memref.free operations were generating calls to hardcoded 'malloc' and 'free' f

[MLIR] Generic 'malloc', 'aligned_alloc' and 'free' functions

When converted to the LLVM dialect, the memref.alloc and memref.free operations were generating calls to hardcoded 'malloc' and 'free' functions. This didn't leave any freedom to users to provide their custom implementation. Those operations now convert into calls to '_mlir_alloc' and '_mlir_free' functions, which have also been implemented into the runtime support library as wrappers to 'malloc' and 'free'. The same has been done for the 'aligned_alloc' function.

Reviewed By: ftynse

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

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

[mlir][llvm] Add a test for memref.copy lowering to llvm

This was missing and also there was a bug in the lowering itself, which went unnoticed due to it.

Differential Revision: https://reviews.llv

[mlir][llvm] Add a test for memref.copy lowering to llvm

This was missing and also there was a bug in the lowering itself, which went unnoticed due to it.

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

show more ...

Revert "Revert "[mlir][memref] Implement lowering of memref.copy to llvm""

This reverts commit 7d6e589fc86d7865fc4bf92c583209700dd32aac.

Windows build was unbroken.

Revert "[mlir][memref] Implement lowering of memref.copy to llvm"

This reverts commit e9396449777f02d573deb25d603ee1b1d6e568c1.

Breaks Windows build.

[mlir][memref] Implement lowering of memref.copy to llvm

This lowering uses a library call to implement copying in the general case, i.e.,
supporting arbitrary rank and strided layouts.

[mlir][LLVM] NFC - Refactor a lookupOrCreateFn to reuse common function creation.

Differential revision: https://reviews.llvm.org/D96488