<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/mlir/test/CAPI/execution_engine.c, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>Revert "[MLIR] Split ExecutionEngine Initialization out of ctor into an explicit method call" (#153477)</title>
<updated>2025-08-13T19:43:04+00:00</updated>
<author>
<name>Mehdi Amini</name>
<email>joker.eph@gmail.com</email>
</author>
<published>2025-08-13T19:43:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=bfd490e0cda0917dfc357ca87f3c0639ba38a56f'/>
<id>bfd490e0cda0917dfc357ca87f3c0639ba38a56f</id>
<content type='text'>
Reverts llvm/llvm-project#153373

Sanitizer bot is broken</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverts llvm/llvm-project#153373

Sanitizer bot is broken</pre>
</div>
</content>
</entry>
<entry>
<title>[MLIR] Split ExecutionEngine Initialization out of ctor into an explicit method call (#153373)</title>
<updated>2025-08-13T13:22:01+00:00</updated>
<author>
<name>Shenghang Tsai</name>
<email>jackalcooper@gmail.com</email>
</author>
<published>2025-08-13T13:22:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2f93693f76fab9841810ef988087c95887728a91'/>
<id>2f93693f76fab9841810ef988087c95887728a91</id>
<content type='text'>
This PR introduces a mechanism to defer JIT engine initialization,
enabling registration of required symbols before global constructor
execution.

## Problem

Modules containing `gpu.module` generate global constructors (e.g.,
kernel load/unload) that execute *during* engine creation. This can
force premature symbol resolution, causing failures when:
- Symbols are registered via `mlirExecutionEngineRegisterSymbol` *after*
creation
- Global constructors exist (even if not directly using unresolved
symbols, e.g., an external function declaration)
   - GPU modules introduce mandatory binary loading logic

## Usage
```c
// Create engine without initialization
MlirExecutionEngine jit = mlirExecutionEngineCreate(...);

// Register required symbols
mlirExecutionEngineRegisterSymbol(jit, ...);

// Explicitly initialize (runs global constructors)
mlirExecutionEngineInitialize(jit);
```

---------

Co-authored-by: Mehdi Amini &lt;joker.eph@gmail.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This PR introduces a mechanism to defer JIT engine initialization,
enabling registration of required symbols before global constructor
execution.

## Problem

Modules containing `gpu.module` generate global constructors (e.g.,
kernel load/unload) that execute *during* engine creation. This can
force premature symbol resolution, causing failures when:
- Symbols are registered via `mlirExecutionEngineRegisterSymbol` *after*
creation
- Global constructors exist (even if not directly using unresolved
symbols, e.g., an external function declaration)
   - GPU modules introduce mandatory binary loading logic

## Usage
```c
// Create engine without initialization
MlirExecutionEngine jit = mlirExecutionEngineCreate(...);

// Register required symbols
mlirExecutionEngineRegisterSymbol(jit, ...);

// Explicitly initialize (runs global constructors)
mlirExecutionEngineInitialize(jit);
```

---------

Co-authored-by: Mehdi Amini &lt;joker.eph@gmail.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>[MLIR] Add SystemZ arg extensions for some tests (#116314)</title>
<updated>2024-11-19T16:31:33+00:00</updated>
<author>
<name>Jonas Paulsson</name>
<email>paulson1@linux.ibm.com</email>
</author>
<published>2024-11-19T16:31:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0d9dc421143a0acd414a23f343b555c965a471f1'/>
<id>0d9dc421143a0acd414a23f343b555c965a471f1</id>
<content type='text'>
The SystemZ ABI requires that i32 values should be extended when passed
between functions.

This patch fixes some tests that were lacking this, either by adding
some SystemZ specific inlinings of test functions or by disabling the
verification of this with the CL option controlling this.

Fixes #115564</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The SystemZ ABI requires that i32 values should be extended when passed
between functions.

This patch fixes some tests that were lacking this, either by adding
some SystemZ specific inlinings of test functions or by disabling the
verification of this with the CL option controlling this.

Fixes #115564</pre>
</div>
</content>
</entry>
<entry>
<title>[MLIR][OpenMP] Remove terminators from loop wrappers (#112229)</title>
<updated>2024-10-15T10:28:39+00:00</updated>
<author>
<name>Sergio Afonso</name>
<email>safonsof@amd.com</email>
</author>
<published>2024-10-15T10:28:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0a17bdfc361400cb511368f2edfc68c0d11e1974'/>
<id>0a17bdfc361400cb511368f2edfc68c0d11e1974</id>
<content type='text'>
This patch simplifies the representation of OpenMP loop wrapper
operations by introducing the `NoTerminator` trait and updating
accordingly the verifier for the `LoopWrapperInterface`.

Since loop wrappers are already limited to having exactly one region
containing exactly one block, and this block can only hold a single
`omp.loop_nest` or loop wrapper and an `omp.terminator` that does not
return any values, it makes sense to simplify the representation of loop
wrappers by removing the terminator.

There is an extensive list of Lit tests that needed updating to remove
the `omp.terminator`s adding some noise to this patch, but actual
changes are limited to the definition of the `omp.wsloop`, `omp.simd`,
`omp.distribute` and `omp.taskloop` loop wrapper ops, Flang lowering for
those, `LoopWrapperInterface::verifyImpl()`, SCF to OpenMP conversion
and OpenMP dialect documentation.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch simplifies the representation of OpenMP loop wrapper
operations by introducing the `NoTerminator` trait and updating
accordingly the verifier for the `LoopWrapperInterface`.

Since loop wrappers are already limited to having exactly one region
containing exactly one block, and this block can only hold a single
`omp.loop_nest` or loop wrapper and an `omp.terminator` that does not
return any values, it makes sense to simplify the representation of loop
wrappers by removing the terminator.

There is an extensive list of Lit tests that needed updating to remove
the `omp.terminator`s adding some noise to this patch, but actual
changes are limited to the definition of the `omp.wsloop`, `omp.simd`,
`omp.distribute` and `omp.taskloop` loop wrapper ops, Flang lowering for
those, `LoopWrapperInterface::verifyImpl()`, SCF to OpenMP conversion
and OpenMP dialect documentation.</pre>
</div>
</content>
</entry>
<entry>
<title>[MLIR][OpenMP] Make omp.wsloop into a loop wrapper (1/5) (#89209)</title>
<updated>2024-04-24T13:22:59+00:00</updated>
<author>
<name>Sergio Afonso</name>
<email>safonsof@amd.com</email>
</author>
<published>2024-04-24T13:22:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=07e6c1609d0a57f7ddc0537b7794be2e0296658b'/>
<id>07e6c1609d0a57f7ddc0537b7794be2e0296658b</id>
<content type='text'>
This patch updates the definition of `omp.wsloop` to enforce the
restrictions of a loop wrapper operation.

Related tests are updated but this PR on its own will not pass premerge
tests. All patches in the stack are needed before it can be compiled and
passes tests.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch updates the definition of `omp.wsloop` to enforce the
restrictions of a loop wrapper operation.

Related tests are updated but this PR on its own will not pass premerge
tests. All patches in the stack are needed before it can be compiled and
passes tests.</pre>
</div>
</content>
</entry>
<entry>
<title>Activate OpenMP translation in MLIR execution engine CAPI.</title>
<updated>2023-06-05T18:56:50+00:00</updated>
<author>
<name>Rafael Ubal Tena</name>
<email>rubal@mathworks.com</email>
</author>
<published>2023-06-05T18:56:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=db7cc0348c9a0aa44b23948949afef488d5083dd'/>
<id>db7cc0348c9a0aa44b23948949afef488d5083dd</id>
<content type='text'>
We've observed that the MLIR Jit Engine fails when the `omp` dialect is used due to a failure to register OpenMP-related translations. This small patch addresses this issue.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D151577
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We've observed that the MLIR Jit Engine fails when the `omp` dialect is used due to a failure to register OpenMP-related translations. This small patch addresses this issue.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D151577
</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][CAPI] Allow running pass manager on any operation</title>
<updated>2023-03-01T23:17:13+00:00</updated>
<author>
<name>rkayaith</name>
<email>rkayaith@gmail.com</email>
</author>
<published>2022-11-09T03:39:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6f5590ca347a5a2467b8aaea4b24bc9b70ef138f'/>
<id>6f5590ca347a5a2467b8aaea4b24bc9b70ef138f</id>
<content type='text'>
`mlirPassManagerRun` is currently restricted to running on
`builtin.module` ops, but this restriction doesn't exist on the C++
side. This renames it to `mlirPassManagerRunOnOp` and updates it to take
`MlirOperation` instead of `MlirModule`.

Depends on D143352

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D143354
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
`mlirPassManagerRun` is currently restricted to running on
`builtin.module` ops, but this restriction doesn't exist on the C++
side. This renames it to `mlirPassManagerRunOnOp` and updates it to take
`MlirOperation` instead of `MlirModule`.

Depends on D143352

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D143354
</pre>
</div>
</content>
</entry>
<entry>
<title>Reland "[mlir][func] Use the generated pass options in func to llvm."</title>
<updated>2023-02-11T11:29:10+00:00</updated>
<author>
<name>Tobias Gysi</name>
<email>tobias.gysi@nextsilicon.com</email>
</author>
<published>2023-02-11T11:27:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5dc34eb379f40614d5c2381d46e5c8d6d6af63fd'/>
<id>5dc34eb379f40614d5c2381d46e5c8d6d6af63fd</id>
<content type='text'>
Update the FuncToLLVM pass to use the generated constructors and
the generated pass option struct. The hand written constructor
got out of sync after some refactorings. Using a generated constructor
and options struct ensures the everything remains in sync.

Reviewed By: zero9178

This reverts commit 39da46826da82c24ca4407c13ad7feb8e5dc32a1
and relands commit 771d9c05afc2515b474fb53db857716dfdfc1dcf

which was originally reverted due to
https://lab.llvm.org/buildbot#builders/61/builds/39694

Differential Revision: https://reviews.llvm.org/D143733
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Update the FuncToLLVM pass to use the generated constructors and
the generated pass option struct. The hand written constructor
got out of sync after some refactorings. Using a generated constructor
and options struct ensures the everything remains in sync.

Reviewed By: zero9178

This reverts commit 39da46826da82c24ca4407c13ad7feb8e5dc32a1
and relands commit 771d9c05afc2515b474fb53db857716dfdfc1dcf

which was originally reverted due to
https://lab.llvm.org/buildbot#builders/61/builds/39694

Differential Revision: https://reviews.llvm.org/D143733
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[mlir][func] Use the generated pass options in func to llvm."</title>
<updated>2023-02-11T09:42:20+00:00</updated>
<author>
<name>Tobias Gysi</name>
<email>tobias.gysi@nextsilicon.com</email>
</author>
<published>2023-02-11T09:42:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=39da46826da82c24ca4407c13ad7feb8e5dc32a1'/>
<id>39da46826da82c24ca4407c13ad7feb8e5dc32a1</id>
<content type='text'>
The commit breaks the mlir-vulkan runner:
https://lab.llvm.org/buildbot#builders/61/builds/39694

This reverts commit 771d9c05afc2515b474fb53db857716dfdfc1dcf.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The commit breaks the mlir-vulkan runner:
https://lab.llvm.org/buildbot#builders/61/builds/39694

This reverts commit 771d9c05afc2515b474fb53db857716dfdfc1dcf.
</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][func] Use the generated pass options in func to llvm.</title>
<updated>2023-02-11T09:31:19+00:00</updated>
<author>
<name>Tobias Gysi</name>
<email>tobias.gysi@nextsilicon.com</email>
</author>
<published>2023-02-11T09:31:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=771d9c05afc2515b474fb53db857716dfdfc1dcf'/>
<id>771d9c05afc2515b474fb53db857716dfdfc1dcf</id>
<content type='text'>
Update the FuncToLLVM pass to use the generated constructors and
the generated pass option struct. The hand written constructor
got out of sync after some refactorings. Using a generated constructor
and options struct ensures the everything remains in sync.

Reviewed By: zero9178

Differential Revision: https://reviews.llvm.org/D143733
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Update the FuncToLLVM pass to use the generated constructors and
the generated pass option struct. The hand written constructor
got out of sync after some refactorings. Using a generated constructor
and options struct ensures the everything remains in sync.

Reviewed By: zero9178

Differential Revision: https://reviews.llvm.org/D143733
</pre>
</div>
</content>
</entry>
</feed>
