<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in vector-transfer-full-partial-split.mlir</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>ad1d60c3 - [FileCheck] Catch missspelled directives.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#ad1d60c3</link>
        <description>[FileCheck] Catch missspelled directives.Reviewed By: MaskRayDifferential Revision: https://reviews.llvm.org/D125604

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Thu, 26 May 2022 08:48:01 +0000</pubDate>
        <dc:creator>Ivan Kosarev &lt;ivan.kosarev@amd.com&gt;</dc:creator>
    </item>
<item>
        <title>4c807f2f - [mlir][vector] insert `alloca`s outside of loops</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#4c807f2f</link>
        <description>[mlir][vector] insert `alloca`s outside of loopsAfter https://reviews.llvm.org/D119743 added the `AutomaticAllocationScope`trait to loop-like constructs, the vector transfer full/partial splitting passstarted inserting allocations for temporaries within the closest loop ratherthan the closest function (or other allocation scope such as `async.execute`).While this is correct as long as the lowered code takes care of automaticdeallocation at the end of each iteration of the loop, this interferes withdownstream optimizations that expect `alloca`s to be at the function level.Step over loops when looking for the closest allocation scope in vectortransfer full/partial splitting pass thus restoring the original behavior.Reviewed By: hanchungDifferential Revision: https://reviews.llvm.org/D124366

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Mon, 25 Apr 2022 08:25:59 +0000</pubDate>
        <dc:creator>Alex Zinenko &lt;zinenko@google.com&gt;</dc:creator>
    </item>
<item>
        <title>0fd3a1ce - [mlir][NFC] Update remaining textual references of un-namespaced `func` operations</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#0fd3a1ce</link>
        <description>[mlir][NFC] Update remaining textual references of un-namespaced `func` operationsThe special case parsing of operations in the `func` dialect is being removed, andoperations will require the dialect namespace prefix.

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Thu, 21 Apr 2022 04:39:02 +0000</pubDate>
        <dc:creator>River Riddle &lt;riddleriver@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>c48e3a13 - [mlir][NFC] Update textual references of `func` to `func.func` in Tensor/Tosa/Vector tests</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#c48e3a13</link>
        <description>[mlir][NFC] Update textual references of `func` to `func.func` in Tensor/Tosa/Vector testsThe special case parsing of `func` operations is being removed.

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Wed, 20 Apr 2022 23:19:48 +0000</pubDate>
        <dc:creator>River Riddle &lt;riddleriver@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>7294be2b - [mlir][linalg] Replace linalg.fill by OpDSL variant.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#7294be2b</link>
        <description>[mlir][linalg] Replace linalg.fill by OpDSL variant.The revision removes the linalg.fill operation and renames the OpDSL generated linalg.fill_tensor operation to replace it. After the change, all named structured operations are defined via OpDSL and there are no handwritten operations left.A side-effect of the change is that the pretty printed form changes from:```%1 = linalg.fill(%cst, %0) : f32, tensor&lt;?x?xf32&gt; -&gt; tensor&lt;?x?xf32&gt;```changes to```%1 = linalg.fill ins(%cst : f32) outs(%0 : tensor&lt;?x?xf32&gt;) -&gt; tensor&lt;?x?xf32&gt;```Additionally, the builder signature now takes input and output value ranges as it is the case for all other OpDSL operations:```rewriter.create&lt;linalg::FillOp&gt;(loc, val, output)```changes to```rewriter.create&lt;linalg::FillOp&gt;(loc, ValueRange{val}, ValueRange{output})```All other changes remain minimal. In particular, the canonicalization patterns are the same and the `value()`, `output()`, and `result()` methods are now implemented by the FillOpInterface.Depends On D120726Reviewed By: nicolasvasilacheDifferential Revision: https://reviews.llvm.org/D120728

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Mon, 14 Mar 2022 10:45:04 +0000</pubDate>
        <dc:creator>gysit &lt;gysit@google.com&gt;</dc:creator>
    </item>
<item>
        <title>3c3810e7 - [mlir][vector] Avoid hoisting alloca&apos;ed temporary buffers across AutomaticAllocationScope</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#3c3810e7</link>
        <description>[mlir][vector] Avoid hoisting alloca&apos;ed temporary buffers across AutomaticAllocationScopeThis revision avoids incorrect hoisting of alloca&apos;d buffers across an AutomaticAllocationScope boundary.In the more general case, we will probably need a ParallelScope-like interface.Differential Revision: https://reviews.llvm.org/D118768

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Wed, 02 Feb 2022 10:21:02 +0000</pubDate>
        <dc:creator>Nicolas Vasilache &lt;ntv@google.com&gt;</dc:creator>
    </item>
<item>
        <title>ebc81537 - Revert &quot;Revert &quot;[mlir] Purge `linalg.copy` and use `memref.copy` instead.&quot;&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#ebc81537</link>
        <description>Revert &quot;Revert &quot;[mlir] Purge `linalg.copy` and use `memref.copy` instead.&quot;&quot;This reverts commit 25bf6a2a9bc6ecb3792199490c70c4ce50a94aea.

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Tue, 01 Feb 2022 17:07:33 +0000</pubDate>
        <dc:creator>Alexander Belyaev &lt;pifon@google.com&gt;</dc:creator>
    </item>
<item>
        <title>25bf6a2a - Revert &quot;[mlir] Purge `linalg.copy` and use `memref.copy` instead.&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#25bf6a2a</link>
        <description>Revert &quot;[mlir] Purge `linalg.copy` and use `memref.copy` instead.&quot;This reverts commit 016956b68081705ffee511c334e31e414fa1ddbf.Reverting it to fix NVidia build without being in a hurry.

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Mon, 31 Jan 2022 17:51:39 +0000</pubDate>
        <dc:creator>Alexander Belyaev &lt;pifon@google.com&gt;</dc:creator>
    </item>
<item>
        <title>016956b6 - [mlir] Purge `linalg.copy` and use `memref.copy` instead.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#016956b6</link>
        <description>[mlir] Purge `linalg.copy` and use `memref.copy` instead.Differential Revision: https://reviews.llvm.org/D118028

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Mon, 31 Jan 2022 17:18:28 +0000</pubDate>
        <dc:creator>Alexander Belyaev &lt;pifon@google.com&gt;</dc:creator>
    </item>
<item>
        <title>a54f4eae - [MLIR] Replace std ops with arith dialect ops</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#a54f4eae</link>
        <description>[MLIR] Replace std ops with arith dialect opsPrecursor: https://reviews.llvm.org/D110200Removed redundant ops from the standard dialect that were moved to the`arith` or `math` dialects.Renamed all instances of operations in the codebase and in tests.Reviewed By: rriddle, jpienaarDifferential Revision: https://reviews.llvm.org/D110797

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Tue, 12 Oct 2021 23:14:57 +0000</pubDate>
        <dc:creator>Mogball &lt;jeffniu22@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>ffdf0a37 - [mlir][vector] Fix bug in vector-transfer-full-partial-split</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#ffdf0a37</link>
        <description>[mlir][vector] Fix bug in vector-transfer-full-partial-splitWhen splitting with linalg.copy, cannot write into the destination alloc directly. Instead, write into a subview of the alloc.Differential Revision: https://reviews.llvm.org/D110512

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Mon, 27 Sep 2021 08:13:11 +0000</pubDate>
        <dc:creator>Matthias Springer &lt;springerm@google.com&gt;</dc:creator>
    </item>
<item>
        <title>a21a6f51 - [mlir][linalg] Change the pretty printed FillOp operand order.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#a21a6f51</link>
        <description>[mlir][linalg] Change the pretty printed FillOp operand order.The patch changes the pretty printed FillOp operand order from output, value to value, output. The change is a follow up to https://reviews.llvm.org/D104121 that passes the fill value using a scalar input instead of the former capture semantics.Differential Revision: https://reviews.llvm.org/D104356

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Wed, 23 Jun 2021 06:28:58 +0000</pubDate>
        <dc:creator>Tobias Gysi &lt;gysit@google.com&gt;</dc:creator>
    </item>
<item>
        <title>88a48999 - Support VectorTransfer splitting on writes also.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#88a48999</link>
        <description>Support VectorTransfer splitting on writes also.VectorTransfer split previously only split read xfer ops. This addsthe same logic to write ops. The resulting code involves 2conditionals for write ops while read ops only needed 1, but the createdops are built upon the same patterns, so pattern matching/expectationsare all consistent other than in regards to the if/else ops.Differential Revision: https://reviews.llvm.org/D102157

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Fri, 07 May 2021 14:19:22 +0000</pubDate>
        <dc:creator>Tres Popp &lt;tpopp@google.com&gt;</dc:creator>
    </item>
<item>
        <title>95f81350 - [mlir] Change vector.transfer_read/write &quot;masked&quot; attribute to &quot;in_bounds&quot;.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#95f81350</link>
        <description>[mlir] Change vector.transfer_read/write &quot;masked&quot; attribute to &quot;in_bounds&quot;.This is in preparation for adding a new &quot;mask&quot; operand. The existing &quot;masked&quot; attribute was used to specify dimensions that may be out-of-bounds. Such transfers can be lowered to masked load/stores. The new &quot;in_bounds&quot; attribute is used to specify dimensions that are guaranteed to be within bounds. (Semantics is inverted.)Differential Revision: https://reviews.llvm.org/D99639

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Wed, 31 Mar 2021 05:59:30 +0000</pubDate>
        <dc:creator>Matthias Springer &lt;springerm@google.com&gt;</dc:creator>
    </item>
<item>
        <title>b2f232b8 - [testsuite] Make testsuite more stable vs canonicalization change.  NFC.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#b2f232b8</link>
        <description>[testsuite] Make testsuite more stable vs canonicalization change.  NFC.Differential Revision: https://reviews.llvm.org/D98998

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Sat, 20 Mar 2021 00:57:47 +0000</pubDate>
        <dc:creator>Chris Lattner &lt;clattner@nondot.org&gt;</dc:creator>
    </item>
<item>
        <title>e2310704 - [MLIR] Create memref dialect and move dialect-specific ops from std.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#e2310704</link>
        <description>[MLIR] Create memref dialect and move dialect-specific ops from std.Create the memref dialect and move dialect-specific opsfrom std dialect to this dialect.Moved ops:AllocOp -&gt; MemRef_AllocOpAllocaOp -&gt; MemRef_AllocaOpAssumeAlignmentOp -&gt; MemRef_AssumeAlignmentOpDeallocOp -&gt; MemRef_DeallocOpDimOp -&gt; MemRef_DimOpMemRefCastOp -&gt; MemRef_CastOpMemRefReinterpretCastOp -&gt; MemRef_ReinterpretCastOpGetGlobalMemRefOp -&gt; MemRef_GetGlobalOpGlobalMemRefOp -&gt; MemRef_GlobalOpLoadOp -&gt; MemRef_LoadOpPrefetchOp -&gt; MemRef_PrefetchOpReshapeOp -&gt; MemRef_ReshapeOpStoreOp -&gt; MemRef_StoreOpSubViewOp -&gt; MemRef_SubViewOpTransposeOp -&gt; MemRef_TransposeOpTensorLoadOp -&gt; MemRef_TensorLoadOpTensorStoreOp -&gt; MemRef_TensorStoreOpTensorToMemRefOp -&gt; MemRef_BufferCastOpViewOp -&gt; MemRef_ViewOpThe roadmap to split the memref dialect from std is discussed here:https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667Differential Revision: https://reviews.llvm.org/D98041

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Wed, 10 Feb 2021 12:53:11 +0000</pubDate>
        <dc:creator>Julian Gross &lt;julian.gross@dfki.de&gt;</dc:creator>
    </item>
<item>
        <title>40d8e4d3 - Revert &quot;[Canonicalizer] Process regions top-down instead of bottom up &amp; reuse existing constants.&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#40d8e4d3</link>
        <description>Revert &quot;[Canonicalizer] Process regions top-down instead of bottom up &amp; reuse existing constants.&quot;This reverts commit b5d9a3c92358349d5444ab28de8ab5b2bee33a01.The commit introduced a memory error in canonicalization/operationwalking that is exposed when compiled with ASAN. It leads to crashes insome &quot;release&quot; configurations.

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Mon, 15 Mar 2021 09:26:41 +0000</pubDate>
        <dc:creator>Alex Zinenko &lt;zinenko@google.com&gt;</dc:creator>
    </item>
<item>
        <title>b5d9a3c9 - [Canonicalizer] Process regions top-down instead of bottom up &amp; reuse existing constants.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#b5d9a3c9</link>
        <description>[Canonicalizer] Process regions top-down instead of bottom up &amp; reuse existing constants.Two changes: 1) Change the canonicalizer to walk the function in top-down order instead of    bottom-up order.  This composes well with the &quot;top down&quot; nature of constant    folding and simplification, reducing iterations and re-evaluation of ops in    simple cases. 2) Explicitly enter existing constants into the OperationFolder table before    canonicalizing.  Previously we would &quot;constant fold&quot; them and rematerialize    them, wastefully recreating a bunch fo constants, which lead to pointless    memory traffic.Both changes together provide a 33% speedup for canonicalize on some mid-sizeCIRCT examples.One artifact of this change is that the constants generated in normal patternapplication get inserted at the top of the function as the patterns are applied.Because of this, we get &quot;inverted&quot; constants more often, which is an aetheticchange to the IR but does permute some testcases.Differential Revision: https://reviews.llvm.org/D98609

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Sun, 14 Mar 2021 20:14:48 +0000</pubDate>
        <dc:creator>Chris Lattner &lt;clattner@nondot.org&gt;</dc:creator>
    </item>
<item>
        <title>a89035d7 - Revert &quot;[MLIR] Create memref dialect and move several dialect-specific ops from std.&quot;</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#a89035d7</link>
        <description>Revert &quot;[MLIR] Create memref dialect and move several dialect-specific ops from std.&quot;This commit introduced a cyclic dependency:Memref dialect depends on Standard because it used ConstantIndexOp.Std depends on the MemRef dialect in its EDSC/Intrinsics.hWorking on a fix.This reverts commit 8aa6c3765b924d86f623d452777eb76b83bf2787.

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Thu, 18 Feb 2021 11:49:52 +0000</pubDate>
        <dc:creator>Alexander Belyaev &lt;pifon@google.com&gt;</dc:creator>
    </item>
<item>
        <title>8aa6c376 - [MLIR] Create memref dialect and move several dialect-specific ops from std.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir#8aa6c376</link>
        <description>[MLIR] Create memref dialect and move several dialect-specific ops from std.Create the memref dialect and move several dialect-specific ops withoutdependencies to other ops from std dialect to this dialect.Moved ops:AllocOp -&gt; MemRef_AllocOpAllocaOp -&gt; MemRef_AllocaOpDeallocOp -&gt; MemRef_DeallocOpMemRefCastOp -&gt; MemRef_CastOpGetGlobalMemRefOp -&gt; MemRef_GetGlobalOpGlobalMemRefOp -&gt; MemRef_GlobalOpPrefetchOp -&gt; MemRef_PrefetchOpReshapeOp -&gt; MemRef_ReshapeOpStoreOp -&gt; MemRef_StoreOpTransposeOp -&gt; MemRef_TransposeOpViewOp -&gt; MemRef_ViewOpThe roadmap to split the memref dialect from std is discussed here:https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667Differential Revision: https://reviews.llvm.org/D96425

            List of files:
            /llvm-project-15.0.7/mlir/test/Dialect/Vector/vector-transfer-full-partial-split.mlir</description>
        <pubDate>Wed, 10 Feb 2021 12:53:11 +0000</pubDate>
        <dc:creator>Julian Gross &lt;julian.gross@dfki.de&gt;</dc:creator>
    </item>
</channel>
</rss>
