<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/mlir/lib/Dialect/Tensor/Transforms/FoldTensorSubsetOps.cpp, 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>[MLIR] Add `InParallelOpInterface` for parallel combining operations (#157736)</title>
<updated>2025-09-12T21:23:00+00:00</updated>
<author>
<name>Alan Li</name>
<email>me@alanli.org</email>
</author>
<published>2025-09-12T21:23:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b87f1b22a8d8a77d5360f201af5ba08adbb0a974'/>
<id>b87f1b22a8d8a77d5360f201af5ba08adbb0a974</id>
<content type='text'>
This commit:
- Introduces a new `InParallelOpInterface`, along with the
`ParallelCombiningOpInterface`, represent the parallel updating
operations we have in a parallel loop of `scf.forall`.
- Change the name of `ParallelCombiningOpInterface` to
`InParallelOpInterface` as the naming was quite confusing.
- `ParallelCombiningOpInterface` now is used to generalize operations
that insert into shared tensors within parallel combining regions.
Previously, only `tensor.parallel_insert_slice` was supported directly
in `scf.InParallelOp` regions.
- `tensor.parallel_insert_slice` now implements
`ParallelCombiningOpInterface`.

This change enables future extensions to support additional parallel
combining operations beyond `tensor.parallel_insert_slice`, which have
different update semantics, so the `in_parallel` region can correctly
and safely represent these kinds of operation without potential mistakes
such as races.

Author credits: @qedawkins</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit:
- Introduces a new `InParallelOpInterface`, along with the
`ParallelCombiningOpInterface`, represent the parallel updating
operations we have in a parallel loop of `scf.forall`.
- Change the name of `ParallelCombiningOpInterface` to
`InParallelOpInterface` as the naming was quite confusing.
- `ParallelCombiningOpInterface` now is used to generalize operations
that insert into shared tensors within parallel combining regions.
Previously, only `tensor.parallel_insert_slice` was supported directly
in `scf.InParallelOp` regions.
- `tensor.parallel_insert_slice` now implements
`ParallelCombiningOpInterface`.

This change enables future extensions to support additional parallel
combining operations beyond `tensor.parallel_insert_slice`, which have
different update semantics, so the `in_parallel` region can correctly
and safely represent these kinds of operation without potential mistakes
such as races.

Author credits: @qedawkins</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][NFC] update `mlir/Dialect` create APIs (23/n) (#149930)</title>
<updated>2025-07-23T14:16:52+00:00</updated>
<author>
<name>Maksim Levental</name>
<email>maksim.levental@gmail.com</email>
</author>
<published>2025-07-23T14:16:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8fff238b2c363b036ce9e7bf7abab3acafc87ab2'/>
<id>8fff238b2c363b036ce9e7bf7abab3acafc87ab2</id>
<content type='text'>
See https://github.com/llvm/llvm-project/pull/147168 for more info.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
See https://github.com/llvm/llvm-project/pull/147168 for more info.</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir] Remove unused includes (NFC) (#148119)</title>
<updated>2025-07-11T18:59:26+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-07-11T18:59:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5e0de68626828009c4cc09e2ce984f9c9634f6f6'/>
<id>5e0de68626828009c4cc09e2ce984f9c9634f6f6</id>
<content type='text'>
These are identified by misc-include-cleaner.  I've filtered out those
that break builds.  Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These are identified by misc-include-cleaner.  I've filtered out those
that break builds.  Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir] Retire additional `let constructor` (NFC) (#139390)</title>
<updated>2025-05-13T09:15:29+00:00</updated>
<author>
<name>lorenzo chelini</name>
<email>l.chelini@icloud.com</email>
</author>
<published>2025-05-13T09:15:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=61536f2781834ffabfa1dc4bf0c9e891e25c9ed4'/>
<id>61536f2781834ffabfa1dc4bf0c9e891e25c9ed4</id>
<content type='text'>
Three main changes:

- The pass createRequestCWrappersPass is renamed as
createLLVMRequestCWrappersPass

- createOptimizeForTargetPass is now under the LLVM namespace. It’s
unclear why the NVVM namespace was used initially, as all passes in
LLVMIR/Transforms/Passes.h consistently reside in the LLVM namespace.

- DuplicateFunctionEliminationPass is now in the func namespace.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Three main changes:

- The pass createRequestCWrappersPass is renamed as
createLLVMRequestCWrappersPass

- createOptimizeForTargetPass is now under the LLVM namespace. It’s
unclear why the NVVM namespace was used initially, as all passes in
LLVMIR/Transforms/Passes.h consistently reside in the LLVM namespace.

- DuplicateFunctionEliminationPass is now in the func namespace.</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][vector] Standardize `base` Naming Across Vector Ops (NFC) (#137859)</title>
<updated>2025-05-12T08:44:50+00:00</updated>
<author>
<name>Andrzej Warzyński</name>
<email>andrzej.warzynski@arm.com</email>
</author>
<published>2025-05-12T08:44:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c45cc3e42019d3dee59b7c6b958ca85d7302efdd'/>
<id>c45cc3e42019d3dee59b7c6b958ca85d7302efdd</id>
<content type='text'>
[mlir][vector] Standardize base Naming Across Vector Ops (NFC)

This change standardizes the naming convention for the argument
representing the value to read from or write to in Vector ops that
interface with Tensors or MemRefs. Specifically, it ensures that all
such ops use the name `base` (i.e., the base address or location to
which offsets are applied).

Updated operations:

* `vector.transfer_read`,
* `vector.transfer_write`.

For reference, these ops already use `base`:

* `vector.load`, `vector.store`, `vector.scatter`, `vector.gather`,
  `vector.expandload`, `vector.compressstore`, `vector.maskedstore`,
  `vector.maskedload`.

This is a non-functional change (NFC) and does not alter the semantics of these
operations. However, it does require users of the XFer ops to switch from
`op.getSource()` to `op.getBase()`.

To ease the transition, this PR temporarily adds a `getSource()` interface
method for compatibility. This is intended for downstream use only and should
not be relied on upstream. The method will be removed prior to the LLVM 21
release.

Implements #131602</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[mlir][vector] Standardize base Naming Across Vector Ops (NFC)

This change standardizes the naming convention for the argument
representing the value to read from or write to in Vector ops that
interface with Tensors or MemRefs. Specifically, it ensures that all
such ops use the name `base` (i.e., the base address or location to
which offsets are applied).

Updated operations:

* `vector.transfer_read`,
* `vector.transfer_write`.

For reference, these ops already use `base`:

* `vector.load`, `vector.store`, `vector.scatter`, `vector.gather`,
  `vector.expandload`, `vector.compressstore`, `vector.maskedstore`,
  `vector.maskedload`.

This is a non-functional change (NFC) and does not alter the semantics of these
operations. However, it does require users of the XFer ops to switch from
`op.getSource()` to `op.getBase()`.

To ease the transition, this PR temporarily adds a `getSource()` interface
method for compatibility. This is intended for downstream use only and should
not be relied on upstream. The method will be removed prior to the LLVM 21
release.

Implements #131602</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir] Enable decoupling two kinds of greedy behavior. (#104649)</title>
<updated>2024-12-20T16:15:48+00:00</updated>
<author>
<name>Jacques Pienaar</name>
<email>jpienaar@google.com</email>
</author>
<published>2024-12-20T16:15:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=09dfc5713d7e2342bea4c8447d1ed76c85eb8225'/>
<id>09dfc5713d7e2342bea4c8447d1ed76c85eb8225</id>
<content type='text'>
The greedy rewriter is used in many different flows and it has a lot of
convenience (work list management, debugging actions, tracing, etc). But
it combines two kinds of greedy behavior 1) how ops are matched, 2)
folding wherever it can.

These are independent forms of greedy and leads to inefficiency. E.g.,
cases where one need to create different phases in lowering and is
required to applying patterns in specific order split across different
passes. Using the driver one ends up needlessly retrying folding/having
multiple rounds of folding attempts, where one final run would have
sufficed.

Of course folks can locally avoid this behavior by just building their
own, but this is also a common requested feature that folks keep on
working around locally in suboptimal ways.

For downstream users, there should be no behavioral change. Updating
from the deprecated should just be a find and replace (e.g., `find ./
-type f -exec sed -i
's|applyPatternsAndFoldGreedily|applyPatternsGreedily|g' {} \;` variety)
as the API arguments hasn't changed between the two.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The greedy rewriter is used in many different flows and it has a lot of
convenience (work list management, debugging actions, tracing, etc). But
it combines two kinds of greedy behavior 1) how ops are matched, 2)
folding wherever it can.

These are independent forms of greedy and leads to inefficiency. E.g.,
cases where one need to create different phases in lowering and is
required to applying patterns in specific order split across different
passes. Using the driver one ends up needlessly retrying folding/having
multiple rounds of folding attempts, where one final run would have
sufficed.

Of course folks can locally avoid this behavior by just building their
own, but this is also a common requested feature that folks keep on
working around locally in suboptimal ways.

For downstream users, there should be no behavioral change. Updating
from the deprecated should just be a find and replace (e.g., `find ./
-type f -exec sed -i
's|applyPatternsAndFoldGreedily|applyPatternsGreedily|g' {} \;` variety)
as the API arguments hasn't changed between the two.</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][tensor] Apply `InsertSliceOfTransferWriteOpFolder` only when `transfer_write` overwrites all elements of `insert_slice` (#108803)</title>
<updated>2024-10-01T21:29:37+00:00</updated>
<author>
<name>Rajveer Singh Bharadwaj</name>
<email>rajveer.developer@icloud.com</email>
</author>
<published>2024-10-01T21:29:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=760ffa4736357dc31c970abcad833027f5ef36b4'/>
<id>760ffa4736357dc31c970abcad833027f5ef36b4</id>
<content type='text'>
Resolves #101708

The updated logic now correctly checks if `transfer_write` completely
overwrites `insert_slice` and only then applies the rewrite for this
pattern.

This check currently covers static sizes, for dynamic sizes
value bounds analysis is needed (see `TODO:`).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Resolves #101708

The updated logic now correctly checks if `transfer_write` completely
overwrites `insert_slice` and only then applies the rewrite for this
pattern.

This check currently covers static sizes, for dynamic sizes
value bounds analysis is needed (see `TODO:`).</pre>
</div>
</content>
</entry>
<entry>
<title>[MLIR][Vector] Implement TransferReadOfExtractSliceOp as MaskableOpRewritePattern (#91960)</title>
<updated>2024-05-16T20:40:56+00:00</updated>
<author>
<name>Hugo Trachino</name>
<email>hugo.trachino@huawei.com</email>
</author>
<published>2024-05-16T20:40:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=1ede503910d3133ea1af8c084fee96ca98c66464'/>
<id>1ede503910d3133ea1af8c084fee96ca98c66464</id>
<content type='text'>
Split of https://github.com/llvm/llvm-project/pull/90835
Adds support for `TransferReadOfExtractSliceOpFolder` when the
`TransferReadOp` is inside a `MaskOp`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Split of https://github.com/llvm/llvm-project/pull/90835
Adds support for `TransferReadOfExtractSliceOpFolder` when the
`TransferReadOp` is inside a `MaskOp`.</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][vector] Remove duplicate tensor subset &lt;-&gt; vector transfer patterns</title>
<updated>2023-07-11T09:12:29+00:00</updated>
<author>
<name>Matthias Springer</name>
<email>me@m-sp.org</email>
</author>
<published>2023-07-11T09:04:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=867afe5e53194607d671dbf1ae5d190793f02d1f'/>
<id>867afe5e53194607d671dbf1ae5d190793f02d1f</id>
<content type='text'>
Remove patterns that fold tensor subset ops into vector transfer ops from the vector dialect. These patterns already exist in the tensor dialect.

Differential Revision: https://reviews.llvm.org/D154932
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove patterns that fold tensor subset ops into vector transfer ops from the vector dialect. These patterns already exist in the tensor dialect.

Differential Revision: https://reviews.llvm.org/D154932
</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][Affine][NFC] Wrap dialect in "affine" namespace</title>
<updated>2023-04-20T02:19:21+00:00</updated>
<author>
<name>Matthias Springer</name>
<email>springerm@google.com</email>
</author>
<published>2023-04-20T02:02:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4c48f016effde67d500fc95290096aec9f3bdb70'/>
<id>4c48f016effde67d500fc95290096aec9f3bdb70</id>
<content type='text'>
This cleanup aligns the affine dialect with all the other dialects.

Differential Revision: https://reviews.llvm.org/D148687
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This cleanup aligns the affine dialect with all the other dialects.

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