<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/mlir/lib/Conversion/FuncToLLVM/FuncToLLVM.cpp, branch users/matthias-springer/replace_uses_of_bbarg</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>[mlir][Transforms] Dialect conversion: Fix `replaceUsesOfBlockArgument`</title>
<updated>2024-11-26T05:22:24+00:00</updated>
<author>
<name>Matthias Springer</name>
<email>mspringer@nvidia.com</email>
</author>
<published>2024-11-26T04:38:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d046db6686dc31a39511422ad8c35ae439f2a7ba'/>
<id>d046db6686dc31a39511422ad8c35ae439f2a7ba</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][func] Fix incorrect API usage in `FuncOpConversion` (#113977)</title>
<updated>2024-10-29T04:19:43+00:00</updated>
<author>
<name>Matthias Springer</name>
<email>me@m-sp.org</email>
</author>
<published>2024-10-29T04:19:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6588073724d3241d90663e45154d806a28bce95a'/>
<id>6588073724d3241d90663e45154d806a28bce95a</id>
<content type='text'>
This commit fixes a case of incorrect dialect conversion API usage
during `FuncOpConversion`. `replaceAllUsesExcept` (same as
`replaceAllUsesWith`) is currently not supported in a dialect
conversion. `replaceUsesOfBlockArgument` should be used instead. It
sometimes works anyway (like in this case), but that's just because of
the way we insert materializations.

This commit is in preparation of merging the 1:1 and 1:N dialect
conversion drivers. (At that point, the current use of
`replaceAllUsesExcept` will no longer work.)</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit fixes a case of incorrect dialect conversion API usage
during `FuncOpConversion`. `replaceAllUsesExcept` (same as
`replaceAllUsesWith`) is currently not supported in a dialect
conversion. `replaceUsesOfBlockArgument` should be used instead. It
sometimes works anyway (like in this case), but that's just because of
the way we insert materializations.

This commit is in preparation of merging the 1:1 and 1:N dialect
conversion drivers. (At that point, the current use of
`replaceAllUsesExcept` will no longer work.)</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][NFC] Mark type converter in `populate...` functions as `const` (#111250)</title>
<updated>2024-10-05T19:32:40+00:00</updated>
<author>
<name>Matthias Springer</name>
<email>me@m-sp.org</email>
</author>
<published>2024-10-05T19:32:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=206fad0e218e83799e49ca15545d997c6c5e8a03'/>
<id>206fad0e218e83799e49ca15545d997c6c5e8a03</id>
<content type='text'>
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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][LLVM] Add operand bundle support (#108933)</title>
<updated>2024-09-26T05:59:37+00:00</updated>
<author>
<name>Sirui Mu</name>
<email>msrlancern@gmail.com</email>
</author>
<published>2024-09-26T05:59:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=fde3c16ac9851e5f030fa410af098063baaf5019'/>
<id>fde3c16ac9851e5f030fa410af098063baaf5019</id>
<content type='text'>
This PR adds LLVM [operand
bundle](https://llvm.org/docs/LangRef.html#operand-bundles) support to
MLIR LLVM dialect. It affects these 3 operations related to making
function calls: `llvm.call`, `llvm.invoke`, and `llvm.call_intrinsic`.

This PR adds two new parameters to each of the 3 operations. The first
parameter is a variadic operand `op_bundle_operands` that contains the
SSA values for operand bundles. The second parameter is a property
`op_bundle_tags` which holds an array of strings that represent the tags
of each operand bundle.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This PR adds LLVM [operand
bundle](https://llvm.org/docs/LangRef.html#operand-bundles) support to
MLIR LLVM dialect. It affects these 3 operations related to making
function calls: `llvm.call`, `llvm.invoke`, and `llvm.call_intrinsic`.

This PR adds two new parameters to each of the 3 operations. The first
parameter is a variadic operand `op_bundle_operands` that contains the
SSA values for operand bundles. The second parameter is a property
`op_bundle_tags` which holds an array of strings that represent the tags
of each operand bundle.</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][LLVM] Improve lowering of `llvm.byval` function arguments (#100028)</title>
<updated>2024-08-09T02:27:54+00:00</updated>
<author>
<name>Diego Caballero</name>
<email>dieg0ca6aller0@gmail.com</email>
</author>
<published>2024-08-09T02:27:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2ac2e9a5b6c97cbf267db1ef322ed21ebceb2aba'/>
<id>2ac2e9a5b6c97cbf267db1ef322ed21ebceb2aba</id>
<content type='text'>
When a function argument is annotated with the `llvm.byval` attribute,
[LLVM expects](https://llvm.org/docs/LangRef.html#parameter-attributes)
the function argument type to be an `llvm.ptr`. For example:

```
func.func (%args0 : llvm.ptr {llvm.byval = !llvm.struct&lt;(i32)&gt;} {
  ...
}
```

Unfortunately, this makes the type conversion context-dependent, which
is something that the type conversion infrastructure (i.e.,
`LLVMTypeConverter` in this particular case) doesn't support. For
example, we may want to convert `MyType` to `llvm.struct&lt;(i32)&gt;` in
general, but to an `llvm.ptr` type only when it's a function argument
passed by value.

To fix this problem, this PR changes the FuncToLLVM conversion logic to
generate an `llvm.ptr` when the function argument has a `llvm.byval`
attribute. An `llvm.load` is inserted into the function to retrieve the
value expected by the argument users.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When a function argument is annotated with the `llvm.byval` attribute,
[LLVM expects](https://llvm.org/docs/LangRef.html#parameter-attributes)
the function argument type to be an `llvm.ptr`. For example:

```
func.func (%args0 : llvm.ptr {llvm.byval = !llvm.struct&lt;(i32)&gt;} {
  ...
}
```

Unfortunately, this makes the type conversion context-dependent, which
is something that the type conversion infrastructure (i.e.,
`LLVMTypeConverter` in this particular case) doesn't support. For
example, we may want to convert `MyType` to `llvm.struct&lt;(i32)&gt;` in
general, but to an `llvm.ptr` type only when it's a function argument
passed by value.

To fix this problem, this PR changes the FuncToLLVM conversion logic to
generate an `llvm.ptr` when the function argument has a `llvm.byval`
attribute. An `llvm.load` is inserted into the function to retrieve the
value expected by the argument users.</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir] Rename memory attribute to memory_effects in llvmir dialect (#100108)</title>
<updated>2024-07-23T12:17:05+00:00</updated>
<author>
<name>Finlay</name>
<email>finlay.marno@codeplay.com</email>
</author>
<published>2024-07-23T12:17:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2eea9d6a2d1c56df5cbe57972029cd1d8263162a'/>
<id>2eea9d6a2d1c56df5cbe57972029cd1d8263162a</id>
<content type='text'>
This commit renames the memory attribute on operations to "memory_effects" to be in line with the naming LLVM IR is using. </content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit renames the memory attribute on operations to "memory_effects" to be in line with the naming LLVM IR is using. </pre>
</div>
</content>
</entry>
<entry>
<title>mlir/LogicalResult: move into llvm (#97309)</title>
<updated>2024-07-02T09:42:33+00:00</updated>
<author>
<name>Ramkumar Ramachandra</name>
<email>ramkumar.ramachandra@codasip.com</email>
</author>
<published>2024-07-02T09:42:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=db791b278a414fb6df1acc1799adcf11d8fb9169'/>
<id>db791b278a414fb6df1acc1799adcf11d8fb9169</id>
<content type='text'>
This patch is part of a project to move the Presburger library into
LLVM.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch is part of a project to move the Presburger library into
LLVM.</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][Conversion] `FuncToLLVM`: Simplify bare-pointer handling (#96393)</title>
<updated>2024-06-24T06:38:26+00:00</updated>
<author>
<name>Matthias Springer</name>
<email>me@m-sp.org</email>
</author>
<published>2024-06-24T06:38:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9e8ccf6b6410a598f94d2ce4c29d753b8609c907'/>
<id>9e8ccf6b6410a598f94d2ce4c29d753b8609c907</id>
<content type='text'>
Before this commit, there used to be a workaround in the
`func.func`/`gpu.func` op lowering when the bare-pointer calling
convention is enabled. This workaround "patched up" the argument
materializations for memref arguments. This can be done directly in the
argument materialization functions (as the TODOs in the code base
indicate).

This commit effectively reverts back to the old implementation
(a664c14001fa2359604527084c91d0864aa131a4) and adds additional checks to
make sure that bare pointers are used only for function entry block
arguments.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before this commit, there used to be a workaround in the
`func.func`/`gpu.func` op lowering when the bare-pointer calling
convention is enabled. This workaround "patched up" the argument
materializations for memref arguments. This can be done directly in the
argument materialization functions (as the TODOs in the code base
indicate).

This commit effectively reverts back to the old implementation
(a664c14001fa2359604527084c91d0864aa131a4) and adds additional checks to
make sure that bare pointers are used only for function entry block
arguments.</pre>
</div>
</content>
</entry>
<entry>
<title>mlir/MathExtras: consolidate with llvm/MathExtras (#95087)</title>
<updated>2024-06-11T22:00:02+00:00</updated>
<author>
<name>Ramkumar Ramachandra</name>
<email>ramkumar.ramachandra@codasip.com</email>
</author>
<published>2024-06-11T22:00:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0fb216fb2fbb49c1fe90c1c3267873a100b1c356'/>
<id>0fb216fb2fbb49c1fe90c1c3267873a100b1c356</id>
<content type='text'>
This patch is part of a project to move the Presburger library into
LLVM.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch is part of a project to move the Presburger library into
LLVM.</pre>
</div>
</content>
</entry>
<entry>
<title>merge code for llvm.emit_c_interface into convertFuncOpToLLVMFuncOp (#92986)</title>
<updated>2024-05-23T21:41:46+00:00</updated>
<author>
<name>drazi</name>
<email>fengxie83@gmail.com</email>
</author>
<published>2024-05-23T21:41:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a4490217fc04f00342501bdc49efcd314e2787da'/>
<id>a4490217fc04f00342501bdc49efcd314e2787da</id>
<content type='text'>
In today's repo, attribute `llvm.emit_c_interface` of func op is handled
outside of `mlir::convertFuncOpToLLVMFuncOp` in `FuncOpConversion`
pattern. In some cases, `FuncOpConversion` can't be directly re-used,
but we still want to re-use the code to emit c interface for
`llvm.emit_c_interface`.

Changes in this PR
* move the code to generate c with "llvm.emit_c_interface" interface
into `mlir::convertFuncOpToLLVMFuncOp` to be able to re-use it.
* added unit test to verify c interface for jit can be generated
correctly if only call `convertFuncOpToLLVMFuncOp`.
* removed `FuncOpConversionBase`

---------

Co-authored-by: Fung Xie &lt;ftse@nvidia.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In today's repo, attribute `llvm.emit_c_interface` of func op is handled
outside of `mlir::convertFuncOpToLLVMFuncOp` in `FuncOpConversion`
pattern. In some cases, `FuncOpConversion` can't be directly re-used,
but we still want to re-use the code to emit c interface for
`llvm.emit_c_interface`.

Changes in this PR
* move the code to generate c with "llvm.emit_c_interface" interface
into `mlir::convertFuncOpToLLVMFuncOp` to be able to re-use it.
* added unit test to verify c interface for jit can be generated
correctly if only call `convertFuncOpToLLVMFuncOp`.
* removed `FuncOpConversionBase`

---------

Co-authored-by: Fung Xie &lt;ftse@nvidia.com&gt;</pre>
</div>
</content>
</entry>
</feed>
