<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/mlir/test/lib/Transforms/TestControlFlowSink.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:NFC] Remove the forward declaration of FuncOp in the mlir namespace</title>
<updated>2022-04-18T19:01:55+00:00</updated>
<author>
<name>River Riddle</name>
<email>riddleriver@gmail.com</email>
</author>
<published>2022-04-18T18:53:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=58ceae9561fbae75fa175244db4e0e4bfe7416fd'/>
<id>58ceae9561fbae75fa175244db4e0e4bfe7416fd</id>
<content type='text'>
FuncOp has been moved to the `func` namespace for a little over a month, the
using directive can be dropped now.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
FuncOp has been moved to the `func` namespace for a little over a month, the
using directive can be dropped now.
</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir] Rework the implementation of TypeID</title>
<updated>2022-04-04T20:52:26+00:00</updated>
<author>
<name>River Riddle</name>
<email>riddleriver@gmail.com</email>
</author>
<published>2022-03-31T00:00:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5e50dd048e3a20cde5da5d7a754dfee775ef35d6'/>
<id>5e50dd048e3a20cde5da5d7a754dfee775ef35d6</id>
<content type='text'>
This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implicit" fallback path to use the name of the type, instead of using
a static template variable (which breaks shared libraries). The major downside to this
is that it adds some additional initialization costs for the implicit path. Given the
use of type names for uniqueness in the fallback, we also no longer allow types
defined in anonymous namespaces to have an implicit TypeID. To simplify defining
an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro
was added to allow for explicitly defining a TypeID directly on an internal class.

To help identify when types are using the fallback, `-debug-only=typeid` can be
used to log which types are using implicit ids.

This change generally only requires changes to the test passes, which are all defined
in anonymous namespaces, and thus can't use the fallback any longer.

Differential Revision: https://reviews.llvm.org/D122775
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implicit" fallback path to use the name of the type, instead of using
a static template variable (which breaks shared libraries). The major downside to this
is that it adds some additional initialization costs for the implicit path. Given the
use of type names for uniqueness in the fallback, we also no longer allow types
defined in anonymous namespaces to have an implicit TypeID. To simplify defining
an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro
was added to allow for explicitly defining a TypeID directly on an internal class.

To help identify when types are using the fallback, `-debug-only=typeid` can be
used to log which types are using implicit ids.

This change generally only requires changes to the test passes, which are all defined
in anonymous namespaces, and thus can't use the fallback any longer.

Differential Revision: https://reviews.llvm.org/D122775
</pre>
</div>
</content>
</entry>
<entry>
<title>[mlir][cf-sink] Accept a callback for sinking operations</title>
<updated>2022-03-28T19:31:23+00:00</updated>
<author>
<name>Mogball</name>
<email>jeffniu22@gmail.com</email>
</author>
<published>2022-03-25T21:13:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b73f1d2c5d92a923c79435e423d7db9d6fa64eac'/>
<id>b73f1d2c5d92a923c79435e423d7db9d6fa64eac</id>
<content type='text'>
(This was a TODO from the initial patch).

The control-flow sink utility accepts a callback that is used to sink an operation into a region.
The `moveIntoRegion` is called on the same operation and region that return true for `shouldMoveIntoRegion`.
The callback must preserve the dominance of the operation within the region. In the default control-flow
sink implementation, this is moving the operation to the start of the entry block.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D122445
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
(This was a TODO from the initial patch).

The control-flow sink utility accepts a callback that is used to sink an operation into a region.
The `moveIntoRegion` is called on the same operation and region that return true for `shouldMoveIntoRegion`.
The callback must preserve the dominance of the operation within the region. In the default control-flow
sink implementation, this is moving the operation to the start of the entry block.

Reviewed By: mehdi_amini

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