[mlir] Move the Builtin FuncOp to the Func dialect

This commit moves FuncOp out of the builtin dialect, and into the Func
dialect. This move has been planned in some capacity from the moment
we made

[mlir] Move the Builtin FuncOp to the Func dialect

This commit moves FuncOp out of the builtin dialect, and into the Func
dialect. This move has been planned in some capacity from the moment
we made FuncOp an operation (years ago). This commit handles the
functional aspects of the move, but various aspects are left untouched
to ease migration: func::FuncOp is re-exported into mlir to reduce
the actual API churn, the assembly format still accepts the unqualified
`func`. These temporary measures will remain for a little while to
simplify migration before being removed.

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

show more ...

[mlir][NFC] Move Translation.h to a Tools/mlir-translate directory

Translation.h is currently awkwardly shoved into the top-level mlir, even though it is
specific to the mlir-translate tool. This co

[mlir][NFC] Move Translation.h to a Tools/mlir-translate directory

Translation.h is currently awkwardly shoved into the top-level mlir, even though it is
specific to the mlir-translate tool. This commit moves it to a new Tools/mlir-translate
directory, which is intended for libraries used to implement tools. It also splits the
translate registry from the main entry point, to more closely mirror what mlir-opt
does.

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

show more ...

[mlir] Add partial support for translating data layout

Add support for translating data layout specifications for integer and float
types between MLIR and LLVM IR. This is a first step towards remov

[mlir] Add partial support for translating data layout

Add support for translating data layout specifications for integer and float
types between MLIR and LLVM IR. This is a first step towards removing the
string-based LLVM dialect data layout attribute on modules. The latter is still
available and will remain so until the first-class MLIR modeling can fully
replace it.

Depends On D120739

Reviewed By: wsmoses

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

show more ...

[mlir] make implementations of translation to LLVM IR interfaces private

There is no need for the interface implementations to be exposed, opaque
registration functions are sufficient for all users,

[mlir] make implementations of translation to LLVM IR interfaces private

There is no need for the interface implementations to be exposed, opaque
registration functions are sufficient for all users, similarly to passes.

Reviewed By: mehdi_amini

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

show more ...

[mlir] Simplify ModuleTranslation for LLVM IR

A series of preceding patches changed the mechanism for translating MLIR to
LLVM IR to use dialect interface with delayed registration. It is no longer

[mlir] Simplify ModuleTranslation for LLVM IR

A series of preceding patches changed the mechanism for translating MLIR to
LLVM IR to use dialect interface with delayed registration. It is no longer
necessary for specific dialects to derive from ModuleTranslation. Remove all
virtual methods from ModuleTranslation and factor out the entry point to be a
free function.

Also perform some cleanups in ModuleTranslation internals.

Depends On D96774

Reviewed By: nicolasvasilache

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

show more ...

[mlir] Use the interface-based translation for LLVM "intrinsic" dialects

Port the translation of five dialects that define LLVM IR intrinsics
(LLVMAVX512, LLVMArmNeon, LLVMArmSVE, NVVM, ROCDL) to th

[mlir] Use the interface-based translation for LLVM "intrinsic" dialects

Port the translation of five dialects that define LLVM IR intrinsics
(LLVMAVX512, LLVMArmNeon, LLVMArmSVE, NVVM, ROCDL) to the new dialect
interface-based mechanism. This allows us to remove individual translations
that were created for each of these dialects and just use one common
MLIR-to-LLVM-IR translation that potentially supports all dialects instead,
based on what is registered and including any combination of translatable
dialects. This removal was one of the main goals of the refactoring.

To support the addition of GPU-related metadata, the translation interface is
extended with the `amendOperation` function that allows the interface
implementation to post-process any translated operation with dialect attributes
from the dialect for which the interface is implemented regardless of the
operation's dialect. This is currently applied to "kernel" functions, but can
be used to construct other metadata in dialect-specific ways without
necessarily affecting operations.

Depends On D96591, D96504

Reviewed By: nicolasvasilache

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

show more ...

[mlir] Use dialect interfaces to translate OpenMP dialect to LLVM IR

Migrate the translation of the OpenMP dialect operations to LLVM IR to the new
dialect-based mechanism.

Depends On D96503

Revie

[mlir] Use dialect interfaces to translate OpenMP dialect to LLVM IR

Migrate the translation of the OpenMP dialect operations to LLVM IR to the new
dialect-based mechanism.

Depends On D96503

Reviewed By: nicolasvasilache

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

show more ...

[mlir] Introduce dialect interfaces for translation to LLVM IR

The existing approach to translation to the LLVM IR relies on a single
translation supporting the base LLVM dialect, extensible through

[mlir] Introduce dialect interfaces for translation to LLVM IR

The existing approach to translation to the LLVM IR relies on a single
translation supporting the base LLVM dialect, extensible through inheritance to
support intrinsic-based dialects also derived from LLVM IR such as NVVM and
AVX512. This approach does not scale well as it requires additional
translations to be created for each new intrinsic-based dialect and does not
allow them to mix in the same module, contrary to the rest of the MLIR
infrastructure. Furthermore, OpenMP translation ingrained itself into the main
translation mechanism.

Start refactoring the translation to LLVM IR to operate using dialect
interfaces. Each dialect that contains ops translatable to LLVM IR can
implement the interface for translating them, and the top-level translation
driver can operate on interfaces without knowing about specific dialects.
Furthermore, the delayed dialect registration mechanism allows one to avoid a
dependency on LLVM IR in the dialect that is translated to it by implementing
the translation as a separate library and only registering it at the client
level.

This change introduces the new mechanism and factors out the translation of the
"main" LLVM dialect. The remaining dialects will follow suit.

Reviewed By: nicolasvasilache

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

show more ...

Check for nullptr before dereferencing in translateModuleToLLVMIR()

This is defensive with respect to invocations of this API with an IR
that isn't ready to be converted to LLVM IR.

[MLIR] NFC : Move OpenMP dialect include to translation

The OpenMP dialect include is only needed for translation
and is not required in LLVM dialect.

Reviewed By: ftynse

Differential Revision: ht

[MLIR] NFC : Move OpenMP dialect include to translation

The OpenMP dialect include is only needed for translation
and is not required in LLVM dialect.

Reviewed By: ftynse

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

show more ...

[MLIR] Avoid adding debuginfo for a function if it contains calls that has no debug info.

Also add a verifier pass to ExecutionEngine.

It's hard to come up with a test case, since mlir-opt always a

[MLIR] Avoid adding debuginfo for a function if it contains calls that has no debug info.

Also add a verifier pass to ExecutionEngine.

It's hard to come up with a test case, since mlir-opt always add location info after parsing it (?)

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

show more ...

Remove dependency from LLVM Dialect on the OpenMP dialect

The OmpDialect is in practice optional during translation to LLVM IR: the code is tolerant
to have a "nullptr" when not present / needed.

T

Remove dependency from LLVM Dialect on the OpenMP dialect

The OmpDialect is in practice optional during translation to LLVM IR: the code is tolerant
to have a "nullptr" when not present / needed.

The dependency still exists on the export to LLVMIR.

Reviewed By: ftynse

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

show more ...

Add a `dialect_registration` callback for "translations" registered with mlir-translate

This will allow out-of-tree translation to register the dialects they expect
to see in their input, on the mod

Add a `dialect_registration` callback for "translations" registered with mlir-translate

This will allow out-of-tree translation to register the dialects they expect
to see in their input, on the model of getDependentDialects() for passes.

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

show more ...

[mlir] take LLVMContext in MLIR-to-LLVM-IR translation

Due to the original type system implementation, LLVMDialect in MLIR contains an
LLVMContext in which the relevant objects (types, metadata) are

[mlir] take LLVMContext in MLIR-to-LLVM-IR translation

Due to the original type system implementation, LLVMDialect in MLIR contains an
LLVMContext in which the relevant objects (types, metadata) are created. When
an MLIR module using the LLVM dialect (and related intrinsic-based dialects
NVVM, ROCDL, AVX512) is converted to LLVM IR, it could only live in the
LLVMContext owned by the dialect. The type system no longer relies on the
LLVMContext, so this limitation can be removed. Instead, translation functions
now take a reference to an LLVMContext in which the LLVM IR module should be
constructed. The caller of the translation functions is responsible for
ensuring the same LLVMContext is not used concurrently as the translation no
longer uses a dialect-wide context lock.

As an additional bonus, this change removes the need to recreate the LLVM IR
module in a different LLVMContext through printing and parsing back, decreasing
the compilation overhead in JIT and GPU-kernel-to-blob passes.

Reviewed By: rriddle, mehdi_amini

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

show more ...

[mlir] Remove need for static global ctors from mlir-translate

Summary: https://bugs.llvm.org/show_bug.cgi?id=45436

Reviewers: mehdi_amini, mravishankar, antiagainst, rriddle, stephenneuendorffer

[mlir] Remove need for static global ctors from mlir-translate

Summary: https://bugs.llvm.org/show_bug.cgi?id=45436

Reviewers: mehdi_amini, mravishankar, antiagainst, rriddle, stephenneuendorffer

Reviewed By: mehdi_amini, rriddle, stephenneuendorffer

Subscribers: frgossen, stephenneuendorffer, jholewinski, mgorny, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, bader, grosul1, llvm-commits

Tags: #llvm

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

show more ...

Mass update the MLIR license header to mention "Part of the LLVM project"

This is an artifact from merging MLIR into LLVM, the file headers are
now aligned with the rest of the project.

Adjust License.txt file to use the LLVM license

PiperOrigin-RevId: 286906740

NFC: Remove unnecessary 'llvm::' prefix from uses of llvm symbols declared in `mlir` namespace.

Aside from being cleaner, this also makes the codebase more consistent.

PiperOrigin-RevId: 286206974

Change MLIR translation functions signature

This CL changes translation functions to take MemoryBuffer
as input and raw_ostream as output. It is generally better to
avoid handling files directly in

Change MLIR translation functions signature

This CL changes translation functions to take MemoryBuffer
as input and raw_ostream as output. It is generally better to
avoid handling files directly in a library (unless the library
is specifically for file manipulation) and we can unify all
file handling to the mlir-translate binary itself.

PiperOrigin-RevId: 269625911

show more ...

NFC: Rename Module to ModuleOp.

Module is a legacy name that only exists as a typedef of ModuleOp.

PiperOrigin-RevId: 257427248

Make TranslateFromMLIRFunction type return LogicalResult instead of bool

This interface was created before MLIR introduced LogicalResult.

PiperOrigin-RevId: 256554557

NFC: Refactor Module to be value typed.

As with Functions, Module will soon become an operation, which are value-typed. This eases the transition from Module to ModuleOp. A new class, OwningModuleRe

NFC: Refactor Module to be value typed.

As with Functions, Module will soon become an operation, which are value-typed. This eases the transition from Module to ModuleOp. A new class, OwningModuleRef is provided to allow for owning a reference to a Module, and will auto-delete the held module on destruction.

PiperOrigin-RevId: 256196193

show more ...

Remove unnecessary C++ specifier in CPP files. NFC.

These are only required in .h files to disambiguate between C and C++ header files.

--

PiperOrigin-RevId: 248219135

Add transformation of the NVVM dialect to an LLVM module. Only handles
the generation of intrinsics out of NVVM index ops for now.

--

PiperOrigin-RevId: 245933152

Introduce std.varargs attribute to mark variadic arguments functions

This is only teaching the LLVM converter to propagate the attribute onto
the function type. MLIR will not recognize this

Introduce std.varargs attribute to mark variadic arguments functions

This is only teaching the LLVM converter to propagate the attribute onto
the function type. MLIR will not recognize this arguments, so it would only
be useful when calling for example `printf` with the same arguments across
a module. Since varargs is part of the ABI lowering, this is not NFC.

--

PiperOrigin-RevId: 242382427

show more ...